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.
Related
I'm part of a small team as a nodeJS dev and I've been tasked into researching how this can be accomplished. I'm fairly new to OAuth and authentication so please bear with me.
Currently we have a next.js webapp that uses NextAuth for authentication with the user store in DynamoDB. What we want to do is provide an Oauth2 flow so a user can consent to a 3rd party service having access to their profile information via an endpoint. In this case we are the resource server, the 3rd party is the "client" and our user is the resource owner.
The piece of the puzzle I'm trying to put together is how does Auth0 work with NextAuth in this scenario? I want Auth0 to check if the user is logged in (otherwise prompting them to do so) via NextAuth, and for NextAuth to say "this is fine" and then for Auth0 to issue a token to the 3rd party (concluding a "normal" OAuth flow). Is this were SAML comes into play? I see there's a software package called SAML Jackson (lol) and there's a Next-auth integration for it.
Most examples I see usually work the other way around, with Auth0 as the identity provider, and what we're doing may be unique. Sorry if this question comes across as abstract but that's how it exists in my mind currently. Any help understanding this would be greatly appreciated.
You can connect your user store to Auth0 as a custom database connection. And then create an application inside Auth0 and enable the DB connection for the app. This way Auth0 acts as the Authorization server for your client app.
NextAuth.js is just an authentication library that supports the OAuth2.0/OpenID protocols. The role of NextAuth is simply to initiate the authentication flow, take the user to the Identity Provider (in this case Auth0 backed by a custom user store) and finally process the authorization response from Auth0. The authorization response (code) is received at the application end and then exchanged for access_token and user profile (all handled by NextAuth.js).
And for your query on SAML, it's a standard for exchanging identity information between two parties an Identity Provider (IdP) and a service provider (SP). The same is achieved by its more modern counterparts OAuth2.0/OpenID Connect. Typically third-party apps which are deployed in an enterprise setting use SAML to integrate with on-premise Identity Management Systems like ActiveDirectory. You can read more about SAML on https://boxyhq.com/blog/understanding-saml-sso-the-basics-from-the-user-side.
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.
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.
We want to deeply integrate OneDrive with our web app in order to handle document and storage data. However, we want the users not to log in twice. I'm not sure whether this is possible, but I've been reading about SSO and SAML and it seems like it's the way to go.
Is it possible, and if so, is Single Sign On the way to go?
Single Sign-On (SSO) is a great solution for user experience when web applications are hosted on different domains. SAML as a standard was developed for cross domain authentication to solve this use case. You will need an Identity Provider (IdP) server that handles authentication of users to your web application and then the IdP Server issues SAML assertions to your web application and OneDrive. Your application in this architecture will be a Service Provider (SP) that will consume SAML assertions, as well as OneDrive is a SP that consumes SAML assertions. There are a number of SSO/Federation vendors that provide the IdP Server.
As far as implementation, once you have chosen and installed the IdP Server, you will need to implement your web application to consume the SAML assertion and configure the IdP Server as a connection. OneDrive will simply be a configuration as it already supports SAML and WS-Federation.
In addition to SAML as a protocol, there are other standards with respect to SSO/Federation such as OpenID Connect (OIDC) and OAuth2. When choosing a IdP Server solution you may want to look at these other protocols that can solve additional use cases. SAML works well for web applications and the use case you have described. OIDC and OAuth2 are better suited for secure APIs and native mobile applications.
Another consideration when looking at an IdP Server is how authentication is to be performed. Options for authentication could be using Kerberos/IWA if all clients are on a common domain, or authentication using a Login Form. You may also want to look at MFA support when looking at an IdP Server as part of the SSO solution.
I am into integration with Magento 2.0, however I have a cakePHP 2.0 application and I want the user to be already logged in after he successfully logged into my cakePHP application.
How can I implement such feature?
Thank you in advance
The standard way to SSO between 2 apps that are hosted in different domains is to use SAML2
In that standard there are 2 type of entities:
Identity Provider (IdP). The entity that authenticates the user and send its info to the SP.
Service Provider (SP). The entity that protect the app, is connected with the IdP and can make access control decision.
Since you are using PHP stack I recommend you to use the simpleSAMLphp software to deploy your IdP.
You will need to decide what gonna be your user data source, CakePHP or Magento, and disable registration and password reset on the source not selected.
So in your project you will need:
Deploy an IdP with simplesamlphp and use as authentication source the database of your cakePHP app (if this source is the selected), removing user registration/password on Magento (otherwise connect Magento's database as your main user source and not let users to be registered on cakePHP).
Enable SAML on cakePHP
Enable SAML on Magento2
The advantage of using this standard instead of custom tricky SSOs mechanism is that you will be able to add to your SSO federation any other app (with SAML support) like Salesforce, Wordpress, Google Apps, Drupal, Joomla...
On this video you can see the Magento2 extension in action (I'm using Onelogin as Identity provider). In this other video you can see simpleSAMLphp in action with Magento1.
Note: I'm the author of the Magento2 SAML extension. Right now there is no other option to add SAML to a Magento2 app and is a complex task so I don't recommend to implement it yourself ;)