We have a homegrown auth system which supports email/phone otp & pwd based login --> issues a HMAC jwt token which our internal apps verify based on an internally shared secret.
We need to build a SSO solution onboarding partner/newly-acquired websites with their own auth systems and user bases.
Target -->
--->>> Seamless cross site navigation , so that end user does not need to sign up in 2 websites.
--->>> Minimum/ no code change to be done on the partner systems
--->>> We wont be able to force a single SSO login for all users who are login in partner websites.
First priority is to solve for navigation to our website from partners.
We need a SSO solution where partners and us will be able to maintain corresponding existing own auth systems , but SSO will kick in only during cross site navigation.
Any suggestions / directions to the approach will be very helpful please.
Researched over multiple solutions . It seems a single login for all partner systems, with a single consolidated user base through a identity-provider is the only approach. But this involves all partner companies scrapping their existing/mature authentication and onboarding all users to a common provider like okta ( which they wont be ready to ).
I am sure I am missing something. Is there a standard way of achieving single sign on across various systems but still maintaining own existing auth systems and user bases . Any help / direction is highly appreciated as I am completely stuck.
Related
I'm currently integrating SSO into a web application using passport-saml. Still fairly new to this and trying to understand all the nuances that comes with it so I've got a few questions that I can't seem to find the answer to:
Question 1
I guess, there are two aspects to the IdP side of things. 1 for the customer and 1 for the organisation hosting the SP. So as the org that has the SP, we would need to have our own IdP account to upload our application with all the relevant SAML settings (let's say Okta for this example). The customers would then be able to find the SP from the catalogue of applications from whatever IdP they're using where they can add it and can use the generated Identity Provider Single Sing-On URL and X.509 to input into the SP's settings. I know Okta has a setting to enable their users to find organisation-managed applications which they may need to enable to be able to find our application once approved by Okta. Am I correct in thinking this?
Question 2
Would this mean that as an org, I would need a presence on each IdP a customer might use? OneLogin, Okta, Active Directory, etc.
Question 3
Are IdP's the same for the most part? As in, would I just need to implement SAML into my back end and users can just enter the Idp URL and their certificate, and this will just work for any IdP that the users might be using?
Question 4
Is uploading an application to an IdP a paid service? I've currently got a sample project that is using Okta as an Idp, got all the settings set up but I've noticed that I can submit the application on Okta as a software vendor. Obviously I can't go through it since it's a sample project and I'm also using a trial account so I don't actually know what this entails
Question 5
Lastly, as I previously mentioned, I've noticed that Allow users to add org-managed apps is an available setting for users so they may need to enable this to find my application. But I've noticed that there are thousands of applications that I can browse through on Okta while having this setting disabled. So Okta -> Applications -> Browse App Integration Catalog, I can find applications like Dropbox, etc. Is it a different process (than q5) for an application to be visible on this list?
Question 6
Is SSO at user level or at organisation level? As in, can users of an organisation have a mixture of different ways of logging in? Like, user 1 has SSO enabled but user 2 doesn't. Is that how it tends to work? Or is it more so, an admin enables SSO for the entirety of the organisation whole organisation?
I'm still trying to piece everything together but hopefully I've asked the right questions to properly set this all up but any other additional information you want to share would be helpful!
Answer 1: You are correct that as the organization that has the SP, you would need to have your own IdP account (for example, with Okta) to upload your application with all the relevant SAML settings. Customers would then be able to find the SP from the catalog of applications from whatever IdP they're using, where they can add it and use the generated Identity Provider Single Sign-On URL and X.509 to input into the SP's settings. You would also need to enable the setting in Okta that allows customers to find organization-managed applications.
Answer 2: Yes, this would mean that as an organization, you would need a presence on each IdP a customer might use. Different IdPs have different ways of setting up and managing SP applications, so you would need to create an account and configure your application on each IdP that you want to support.
Answer 3: IdPs are not all the same, but most of them support SAML, which is the standard for SSO. By implementing SAML into your back-end, you can allow users to enter the IdP URL and certificate, and this should work for most IdPs. However, you should check the documentation and settings of each IdP you want to support to make sure that everything is configured correctly.
Answer 4: It depends on the specific IdP provider. Some providers may offer free or trial plans for uploading and managing SP applications, while others may require a paid subscription. It's best to check the pricing and plans of the specific IdP provider you're using to see if there are any costs associated with uploading and managing your application.
Answer 5: Yes, there may be a different process for an application to be visible in the app integration catalog. Some IdPs, such as Okta, have a public application catalog that includes a wide range of popular applications that are pre-integrated with the IdP. These applications may be accessible to all users regardless of whether the "Allow users to add org-managed apps" setting is enabled. It's worth noting that the specific process for making an app visible to users may vary depending on the IdP provider you're using.
Answer 6: SSO is typically implemented at the organization level, meaning that all users within the organization will use the same SSO method to access various applications. However, it is possible to set up different SSO methods for different groups of users within an organization.
For eg. an admin can enable SSO for all users within the organization, but also set up a separate SSO method for a specific group of users, such as contractors or partners. This way, users within the same organization can have different ways of logging in. Some IdPs may offer more granular control over SSO settings than others.
We want to use SSO for a group of apps (this will include GitLab, probably Drupal and a bunch of small apps I will write in Symfony for various tasks). We would like to currently use Google accounts to authenticate all apps, but because there are limits (I know you can increase them) on how many apps you can have and Google sometimes change what features are free, it would be good to have the option of using our own login down the track if needed.
I have used SimpleSAMLphp in the past with GitLab (using a database to store credentials) and it worked well. Is there a way that I can use the Google Auth as an IDP and have SimpleSAMLphp record the email address to link the accounts etc and allow me to add things like groups etc in to send down to the app when a login happens? I would put a password field in the login table in the database as well so that if we decide to move away from Google we can generate random passwords and continue without too many issues.
The information I find online is for using SimpleSAMLphp as the IDP for gsuite etc (we will be using general Google accounts, not ones in gsuite) and not the other way around. I also couldn't see any Authentication Modules for Google authentication. Are there any tutorials or instructions anywhere on this?
You can accomplish what you are asking fairly easily. Instead of integrating your SPs with Google directly, integrate them with an SSP idP you control, then set up your authentication page (i.e. the page redirected to by your authsource module) to be an SP for Google. Here's what that looks like:
vendor sp -> your SSP idP -> your login app -> your SSP SP -> google idP
This way you end up with only a single Google integration configured for all your vendor integrations. There are numerous benefits to this approach:
You aren't affected by # of integration constraints imposed by google
Since your vendor SP integrations are controlled on your own server, you can easily move to a different cloud-based idP for authentication in the future without having to re-integrate all your SPs
You can easily give your users alternate sign-in choices if you want.
You aren't constrained to SAML or protocols supported by Google. Many vendors still use proprietary token based authentication. These can easily be supported with this setup.
Happy to help with implementation details if you need it.
Please help. I'm aware there are several posts / docs about SSO implementations but I still can't seem to find one that addresses my use case - probably because I'm still new to SSO implementation.
Scenario:
I have an existing Symfony 4 application with existing users. I want so that when users log into the app, they are automatically signed into Outlook Office 365 (web). Exactly the same implementations on https://mysso.centennialcollege.ca/. Please NOTE I do not want office 365 to authorize my app using the code flow approach, rather I want office 365 to recognize users signed into my app as valid identities.
Has anyone implemented this or has ideas please?
Your question is a bit unclear. You're likely going to need to change the existing application in some manner in order to achieve true single sign-on. You'll need to ensure that authentication against the Symphony app leads to the presence of a session that can be used to trigger subsequent sessions in a SSO framework supported by O365.
In your case, I'd take a look at SAML and, more specifically, SimpleSAMLphp.
Are you affiliated with the organization you linked to in some way? Because just by looking at the login page that looks like they've already got some sort of SAML Identity Provider solution... you can just integrate your Symphony app with that IdP in that case, and correlate the principal returned to your SP application from the SAML assertion on successful authentication against the user data in your existing DB. You wouldn't have to use SSP in that case... any kind of SAML middleware would work.
I have come across a number of articles that discuss a similar matter but I cannot find a definitive answer.
My company would like to begin using Identity Server 3, however one of the requirements is to be able to authenticate an external user without them having to manually enter their credentials.
This must be capable of providing single sign on capabilities also as we have 3 different systems and our users should only have to sign in once.
Essentially, the external user has their own CRM.
The CRM holds their username and password for our software.
They then click a button in their CRM to launch our application
This redirects them to our website with a payload containing their credentials
We call a web service to authenticate the user
It is fundamental that we do not change this process for our partners.
Can I implement a custom service provider to provide the authentication or is there some other way of achieving this? If so, could you point me in the right direction for how this can be done?
Many thanks
Craig
I would assume that you'd create a mechanism for their CRM to get a token at the time the client logs into their site and then have them send that token via url to your callback page. This would use the machine-to-machine type grant, or the client-credentials flow. Then that page could validate the token and log the user in. There would have to be some sort of unique identifier between the two systems like email or something. Just an idea.
We have a need to secure our .net web api using open id and OAuth standards. IdentityServer 3 is perfect for us as we have to use our existing user store.
Edited for more clarity:
Our company services multiple customers. Each of our customers have their own database. In our home grown client application when a customer user enters their user/password, we do a lookup to authenticate and that also determines what backend database the app connects to.
We now have a need to allow a couple of trusted partners to access our database resource for specific needs. We have created a web api for them to make specific calls. The web api needs to know what customer the partner is making the call for. The partner is calling the api from services on their side so there is no user interaction.
I am trying to determine the flow to use to accomplish this. I found some pretty good info on flows at https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c.
If I define the client using the Client Credentials flow, I don't know how for them to pass the customer they are making the calls on behalf of. I don't think we want to definate a "Client" for every partner/customer combination, but is this the correct way?
What we had thought of initially is to give an additional user/password or secret key that would tell us the customer, but I am not sure what "flow" for the client would allow this.
Any help or direction would be greatly appreciated.
In case this helps anyone else, we decided to go with a Hybrid flow for these types of requests. We considered designating a service account (user/pw) for each of our customer databases that would give this trusted 3rd part access to them by requesting tokens with the Resource Owner Password Credential flow, but decided against it. We decided against it for all the reasons the standards say not to use it for this use.
If the 3rd party wants to interact with us on the behalf of one of our customers, then they will need to build the UI on their side to redirect to us for user/pw authentication and consent.