I am using Azure Active Directory Business to Consumer(adb2c).
We have designed custom policies, part of Identity Experience Framework(IEF) of Azure for 2 different applications.
One application is using login policy/flow which connects to a 3rd party Identity store.
Another application is using login policy/flow which connects to a different 3rd party Identity store.
Can we achieve SSO between them?
I am trying to use DefaultSSOSessionProvider session provider to skip technical profile which actually connect to 3rd party IDP and complete the login in case of SSO scenario. Getting exceptions while doing this.
Will this be possible or is there any other approach to achieve SSO?
In order to enable SSO for different applications in Azure AD B2C you need to configure SSO at the tenant level. To be able to skip external IdP selection you need to set a TP that leverages the ExternalLoginSSOSessionProvider in the UseTechnicalProfileForSessionManagement attribute of your external IdP TP. Take a look to the following custom policy permalink for a sample.
Finally, the external IdP SSO is controlled by the IdP itself and not by B2C so if some problem arises ensure the IdP SSO is working before validating B2C SSO.
Related
We have in my organization an existing ASP.NET web application built in a SAAS model that our customers (users from different organizations) login through username/password authentication method. Users' credentials are hashed and stored in our database. We are currently working on adding a SSO feature to our application that would allow end-users from certain organizations to login with SSO using their own Identity Provider (Azure AD, Google, Okta, etc.) to perform the user authentication. We are using the OpenId Connect protocol to establish the SSO connection with IdP, and more specifically the Open Web Interface for .NET (OWIN) middleware. We have implemented the following:
Our SAAS application offers customers the ability to opt for SSO authentication through a setting. End-users from these organizations will be authenticating to our application via SSO AND using their own IdP
Our application supports SSO connection from different IdPs (Azure AD, Google, Okta, etc.)
Our application stores SSO connection settings for each customer that opt for SSO authentication (Client Id, Authority, Secret, etc.). All these settings are configurable in our application, they're available upon registration of the application on IdP side.
My question is about the app registration. I know that in order for our application to communicate with IdP and initiate SSO authentication it needs to be registered on related IdP, so that it can create a trust relationship. I am wondering which party should be responsible of the app registration:
My organization owner of the SAAS application? or
Our customers willing to use SSO authentication method?
With option 1, my organization will have to have an "account" on each of the IdPs our customers use for authentication (I feel this is not ideal for us), register our application and have a mechanism to invite our customers IdP to connect to the registered app.
I feel like option 2 would be the best approach for us as we won't have to deal with app registration, as customers will be responsible of registering the application on their own IdP. From my organization end we will just need to deal with SSO connection settings (Client Id, and other...) which will be provided to us by our customers upon app registration. I wanted to check if this is a common situation that some have already experienced, and what would be the best/recommended approach to go with. Thanks.
I am expecting app registration to be performed on customers side.
I would usually recommend that your internal services and APIs only need to trust tokens from one Identity Provider, and in your case you have one openid connect provider inhouse. That then supports your users to authenticate to and optionally authenticate using an external provider, like how the image below tries to show:
In my experience, having your applications trust and handle tokens from multiple sources will be a pain, as many of the external tokens might look slightly different.
Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?
I am aware that this is not the usual way for SAML to work.
The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.
Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.
The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.
Question 1: Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?
Answer:
Definitely No, from the cybersecurity perspective.
Question 2: I am aware that this is not the usual way for SAML to work.
Answer:
Yes. You are correct.
(I) The SAML specification defines three roles: a user, an identity provider (IdP), and a service provider (SP). In the primary use case addressed by SAML, a user requests to access a service or log in to a web application from a service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision for the user, that is, it can decide whether to allow the user to access the service or log in to a web application.
(II) Before delivering the subject-based assertion to the SP, the IdP may request some information from the user (such as a user name and password) in order to authenticate the user. SAML specifies the content of the assertion that is passed from the IdP to the SP.
(II.a) In SAML, one identity provider may provide SAML assertions to many SPs.
(II.b) Similarly, one SP may rely on and trust assertions from many IdPs. This will be the SAML scenario of your web application if your product manager decided to request all 4 different clients of your web application to develop their own SAML IdP. For example, some social websites allow their users to log in to their web account through identity authentication provided by the third-party IdPs such as Google, Facebook, LinkedIn via OAuth 2 protocol or OpenID Connect protocol/OAuth 2 (instead of SAML).
Question 3: The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.
Answer:
If 4 different clients for your web application are supposed to enable a central password via SAML, they can implement their own SAML IdP in completely different technologies or programming language such as Java, PHP, or Scala.
(I) For example,
We developed our former version of Zero-Password Authentication and Authorization System in Java and leveraged Java-based Shibboleth IdP to provide SAML SSO for enterprise applications.
We developed our current version of Zero-Password Authentication and Authorization System with scalability and high availability in Scala to provide SAML SSO natively for enterprise applications without Shibboleth IdP.
(II) No matter which technology or programming language are used by 4 different clients of your web application to implement their own SAML IdP, their SAML IdP only needs to authenticate their users using a central password data store/repository (such as OpenLDAP or MySQL) locally and then deliver the user info using SAML assertion/SAML response to your web application/SAML service provider. Your web application/SAML service provider just needs to map the user info carried by SAML assertion to a local user info of your web application.
Question 4: Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.
Answer:
If the user identity authentication needs to take place centrally in your web application instead of in the SAML IdP, then 4 different clients do NOT need to implement their own SAML IdP from the cybersecurity perspective.
Instead you just need to create and assign different sub-domain to all 4 different clients, that is, all 4 different clients of your web application access different sub-domain, such as client-org1.your-web-app.com, client-org2.your-web-app.com, client-org3.your-web-app.com, client-org4.your-web-app.com.
Note that different sub-domain of your web application displays the same login webpage. Example #1: client-org1.box.com, client-org2.box.com if your clients also subscribe Box account, or Example #2: client-org1.my.salesforce.com, client-org2.my.salesforce.com if your clients also subscribe Salesforce account.
Question 5: The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.
Answer:
Different sub-domain of your web application displays the same login webpage.
4 different clients of your web application access different sub-domain of your web application, users of 4 different clients submit their login and password to your web application (through different sub-domain URL), just like without SSO, and the data store/repository of your web application is supposed to verify the access data (i.e., login username/password) centrally. Then 4 different clients of your web application do NOT need any SAML IdP.
We maintain a website that uses the built-in .NET Core / EF Identity model so all user data is in DB tables. We now have a need to support SSO into another 3rd party system which requires that we host our own IDP with support of SAML 2.0. We don't want to change our identity model or login process for our own website, we just need to return a SAML Response for a user without our website as a response to an SSO request by the 3rd party website. Our site is hosted in Azure as a Web App but we don't use Azure AD for this website which is public facing for external client employees.
Are there any recommendations to create a simple IDP that maps to our existing AspNetUsers database table to retrieve and prepare an SSO Response but doesn't impact our existing identity setup? In all likelihood, we'll have to support other SSO protocols in the future with the same implementation. Do we need to go as far as to implement IdentityServer4, making the existing web app act as both an IDP and a client app?
idsrv4 supports the EF identity model (AFAIK). If it doesn't you could always write your own plugin.
idsrv4 then becomes the IDP and will authenticate against your current DB.
idsrv4 has SAML and WS-Fed plugins to support future SSO.
Your other choice is to implement something like Auth0 that supports authentication against local DB and has full support for SAML and WS-Fed.
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.