The general intent is controlling user details visibility while interacting with third party services.
Our application is using a single sign-on (SSO). Hence third party services should use Keycloak for user authentication. But we would like to provide information about user from our application, not from Keycloak.
For example, Stephen Clark has work email stephen.clark#jourrapide.com and personal email stephen.c#armyspy.com. He is authenticating using Keycloak. After authentication third party service would like to request additional information about Stephen. We would like to send information to third party service based on specific user settings. For instance, if Stephen is using his work profile then our application should send stephen.clark#jourrapide.com as an email to third party service. But the stephen.c#armyspy.com email should be sent for Stephen's personal profile. The same should be done for other user details.
That's why our application should get control after user authentication and send appropriate user details to third party service.
I assume that following options could help us to achieve this goal. But I do not have enough information for implementation. It would be good if you could provide me with some options with implementation examples.
Use the "Post Login Flow" in Keycloak.
Create custom identity provider in Keycloak.
Use the Impersonate user functionality in Keycloak with REST API for switching to required user.
Related
So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
I read many blogs and post in Stackoverflow but could not understand exactly which one is appropriate in which situation.
What I understood till now is, custom authentication handler should be written when user needs to redirected to 3rd party system for authentication and then AuthenticationInfo object is sent to the DefaultLogin module.
Now custom login module is used when there is a need to sync user data into AEM from 3rd Party system.
During the synchronization process custom login module also authenticate user against 3rd party. But this can also be possible in authentication handler also.
If I look at the out of the box SAML authentication handler then it does not have login module to synchronize user data, rather SAML authentication handler itself synchronize user data. Why there is such difference in implementation? Which one is applicable in which scenario? Does login module gives extra level of security?
Please note that Login module has been rewritten and now its call External Identity Provider.
External identity provider does not only sync user data but also authenticate user entered credentials. Lets take an example where you need to authenticate user against 3rd party system (which means you need to ask user to enter username and password through Authentication handler in extracthandler method) and after user enters his/her credentials then you want that credentials to be validated again before granting permission to the repository (in this case you need to write External Identity Provider). One example could be, once user enter credentials then 3rd party system generates some token. Now you can validate this token in your External Identity Provider code by calling some web service endpoint provided by 3rd party.
More details here
We have a web application. We also have a separate customer who already uses Okta to manage his employee's access to various applications. This client wants to use Okta SSO for login to our app.
We created a trial Okta account and integrated a "login with Okta" button based on documentation here for a Node/Angular App https://developer.okta.com/quickstart/#/angular/nodejs/generic
This method allows authentication for users who have an account in our Okta. However, this does not seem right as future customers would have users tied to their own accounts.
How do we solve this? Do we need to register with OIN and only then it is possible for other Okta accounts to enable SSO into our app?
You can enable self-registration for your organization and then people can create their own accounts in Okta if they don’t have one.
https://help.okta.com/en/prod/Content/Topics/Directory/Directory_Self_Service_Registration.htm
It seems to me that your customer is looking for a B2B authentication solution with your service.
To accomplish that you will need to allow a SAML inbound federation between his OKTA tenant and yours. by doing that, any user from his OKTA tenant that will log-in to your service will be created instantly at your OKTA tenant and allowed access.
OKTA have made a great tool for that called OKTA org-2-org which includes both authentication and the feature of synching data about the user from his tenant to yours.
https://saml-doc.okta.com/SAML_Docs/Configure-SAML-2.0-for-Org2Org.html
Our company maintains a Web App composed of a front-end and a back-end in (Node.js), and we support the standard username/password login authentication. A couple of our partners have requested we support SAML SSO, so their end-users can access our web app through a link on their respective portals without the need to login again.
Question: Do we need to turn our app into a full-fledged service provider (SP) by implementing a SAML sdk/library in our front-end and back-end?
Or is it possible to use a 3rd party authentication provider like Okta to handle the SAML nitty-gritty behind the scenes and then redirect the end user to our app, with possibly a token (JWT?) so we can retrieve the user info from Okta?
I've read everything I could find on Okta's site, and here, and couldn't find a definitive answer, either yes it's possible (with example) or no you can't do that.
Like you already mentioned in your question, there are 2 possible ways to do it.
Update your application to support SAML login flow with your app as SP, in which case you will not need to use any 3rd party auth provider
If you don't want to get into the SAML nitty-gritty, you can use a 3rd party provider like Okta as an intermediary that will consume the SAML responses from the IdP (used by your external customers) and then convert that assertion into an Open ID token (JWT). In this case, Okta will act as an IdP (Authorization server) to your web app and generate ID tokens.
Your app will then need to implement the Open ID connect login flow.
You can refer to http://developer.okta.com/code/javascript/okta_sign-in_widget_ref for this.
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.