I have an application (App A) that does not implement SSO. It uses its own datastore to authenticate users. What we've been tasked to do is when a user clicks on a button within our application (App A) it needs to redirect the user to another third-party application (App B), authenticate via SAML, and pass data in that payload.
How would I implement this without changing my apps current authentication process? I can't seem to find any resources on using SAML to connect to third-party applications from non-sso applications.
In order to use SAML, you need one side to be the SP (App B) and the other side to be a SAML IDP (App B).
So you need to have SAML on the RP and on the IDP (App B) where you need to authenticate.
This is because SAML is an SSO protocol that needs both sides to conform.
So the button you add needs to use a client-side SAML stack to kick off the process.
Related
Microsof ADFS supports below federation protocols:
SAML 2.0
WS-Federation
OpenID Connect
Would like to know is it possible to achieve single sign on (SSO) and single logout across different protocols? E.g. user X after he/she successfully login to website A which is protected under SAML 2.0, then the user can access website B which is protected under OpenID Connect without re-login? Both website A and website B point to the same IdP.
There are typically the parties involved. Of these, website B is the modern architecture and can support many forms of authentication:
Website A redirects to SAML Identity Provider (IDP) directly
Website B redirects to Authorization Server (AS) which redirects to the SAML IDP
Single Sign On is represented by a third party session cookie issued for the SAML IDP's domain name. Both apps would redirect to the SAML IDP but only the first would result in a login prompt. Website B may need to send the acr_values OpenID Connect parameter during its redirect, to avoid the user being presented with an authentication selection screen. It should work fine, but test for your providers. The SSO cookie is maintained in current browsers on the second redirect, due to the user gesture of a top level redirect.
Single Sign Out has always been a set of draft standards that work imperfectly in all of the above protocols. Even if the technology works, there would be risks such as also signing the user out of App C, which you do not own. Also, recent browser restrictions on third party cookies mean some techniques may drop the SSO cookie and no longer work. Most stakeholders, including end users and security reviewers, do not expect you to have a perfect Single Logout solution.
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.
I have a scenario where I have four to five web based application, which needs to have a common centralized authentication system, in this case how feasible is the SAML based approach i.e each time user want to access any of these web application the user is redirected to SAML server which in return redirects to the IDP, or is their some better solution for such architecture as I am new to the this domain
What you describe is exactly what SAML is designed to solve.
The user is normally only redirected to the SAML Identity Provider (Idp) on the first access to an application (a service provider (SP)). When the user is successfully authenticated by the Idp, the SP sets a cookie in the user's browser to handle authentication of subsequent requests.
I have an application workflow like this
(A) User-Agent (browser) <-----> (B) App Server <------> (C) REST service
Suppose the app server (B) is a SAML service provider and user#domain authenticates from the browser (A) to the app server (B) using the Web Browser SSO profile.
How can an application running on (B) authenticate to a REST service (C) as user#domain.com?
(Assuming B and C are both SAML SP's on the same IdP.)
If the browser were just making AJAX calls to both B and C, it would be straightforward. But if the REST service is invoked directly from the application, what do you do?
What I'm struggling with: If the application itself is not the SAML SP, but integrated with one (say, using Shibboleth SP and the REMOTE_USER header) your application may never see a SAML assertion. You know the user is logged in and authenticated against an IdP but have no way to get a SAML assertion to hand off to the backend service.
Is there a solution or am I out of luck?
Yes, there is nothing preventing your App Server (B) to both act as a service provider accepting the incoming assertions from A and acting as an identity provider, issuing its own SAML ticket that it forwards to C.
If you don't have access to the original assertion you will have to issue a new assertion in B. If you do have access to the original assertion you could forward it to C, if C is configured to ignore audience restrictions that limits the assertion to only be valid for B.
Since you're saying App Server B and REST service C are both SAML SPs with the same SAML IdP, you must already have a mechanism in place which allows a web client to authenticate against C directly (independently of B) via the SAML Web Browser SSO Profile, right? And when this "login workflow" has been completed, the API client has an auth token which represents the fact that "user#domain.com is authenticated by IdP X to use SP C", and can be used to authenticate calls to C for some period of time (until the auth token expires).
But B and C are separate services. And if they have different SAML Service Provider entityIDs registered with the same IdP X, then IdP X will not consider these statements to be equivalent:
user#domain.com is authenticated by IdP X to use SP C
user#domain.com is authenticated by IdP X to use SP B
So there should be no way for service B to use an auth token representing statement 2 above (which it may get from its own SAML SSO login workflow) to get hold of an auth token representing statement 1 above (which can only come from the SAML SSO login workflow for C). Nor should it be possible for service B to "pass through" the API client to the service C SAML SSO login workflow without then losing control over the workflow.
On the other hand, if B and C have the same SAML Service Provider entityID registered with the IdP, then statement 1 above is logically-and-security-wise equivalent to statement 2 above. In this case, the most straightforward solution would be for services B and C to use the same auth token system. Which is really the only way this could work anyway, since if B and C have the same SAML SP entityID then the IdP would have only a single ACS URL configured for both B and C, which means that again as far as the IdP is concerned they are really one and the same SAML SP.