I am a SP developing SAML 2.0 capability for SSO.
The SSO will ALWAYS be initiated from the IdP (Users will get to my site from their Enterprise Portal, where they are already signed in).
So, what I am trying to understand is whether I should just offer unsolicited (IdP initiated) SSO, or is it still best practice to develop solicited (SP initiated) SSO. If the latter, then why do I need the added complexity?
When, as you suggest, users will always be initiated from the IDP - and in fact every IDP that the SP is connected to - then there's no need to add SP initiated SSO support to your SP.
Of course one may argue that having support for SP initiated SSO is more generic and a superset of IDP initiated SSO because you would be able to trigger SSO from outside the IDP portal as well as include SP initiated SSO links in your Enterprise Portal. But in your case the former would never be required so you may stick with IDP initiated SSO only, assuming that all connected IDPs support that.
SP-initiated SSO is best practise in general, and OWASP states that "Unsolicited Response is inherently less secure by design due to the lack of CSRF protection."
Related
I have a web application that is capable of being a SAML 2.0 IdP as well as a SP, and have successfully implemented SSO between my platform and ADFS, but only when ADFS is the IdP.
This is my first foray into integrating with my platform, using ADFS as a SP and I'm having problems understanding the SSO flow.
In my situation, I have three players: WebApp (IdP), ADFS (SP), RelyingParty (S). The trusts are set up in ADFS, and the user experience is supposed to be a successful login to the RelyingParty having logged in to the WebApp
Setting up a new Claims Provider Trust in ADFS with my web app appear to work perfectly. I can go to my app's IdP-initiated URL which sends an unsolicited SAML message to ADFS's ACS URL. When I do this, I get redirected to /idpinitiatedsignon with the message "You are signed in" and a drop-down of the relying parties I've already set up.
If I click on the login button for the RP, ADFS generates a new AuthNRequest to my web app before eventually getting to the Relying Party.
So, seeing this behaviour, I have two questions:
I would have thought that the initial sign in to ADFS via my IdP-initiated login would have got me though to my RP without the need for going back to the IdP for another sign-in. have I misunderstood, or have I just misconfigured ADFS?
What mechanism is ADFS determining that my IdP is to be used? If I go to the ADFS /adfs/ls/idpinitiatedsignon.aspx page in a browser, I've not involved my IdP at all, and selecting my RP does use my IdP to authorize the user but I've no idea how this is determined since there's no link between the Trust Claims Provider and the Relying Party in ADFS configuration.
What happens if you use loginToRp:
https://your-adfs-server/adfs/ls/IdpInitiated.aspx?loginToRp=your:relying:party:id
You have chosen to use IDP Initiated to ADFS. So ADFS handles the authentication.
If you want to involve your IDP, you need to use SP-Initiated flow from the RelyingParty (S).
Then ADFS will show you the Home Realm Discovery screen and you can pick your IDP.
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 working on SAML2.0. One of our clients(IDP) requested us (SP) to have SP initiated requests without sending AuthnRequest.
Instead of sending AuthenRequest they have asked us(SP) to send a parameter on the URL that can tell them that the request has come from the designated SP. Is it an industry standard to implement SP initiated requests without having AuthnRequest parameter?
I would actually call this IDP initiated, as from the viewpoint of SAML, the IDP sends the first message. IDP initiated is part of the standard, so it does not break SAML.
But if you are going to have the SP tell the IDP to start authentication I would consider it bad practise not to have the SP start this by using a SAML AuthnRequest.
This would be a more interoperable approach making it easier to use standard SAML product without the need for customizations.
No it's not. However, from our experience, some IdPs do not support SP-initiated SSO. Instead, they require a redirect to the IdP including a parameter that identifies the SP. This then will trigger IdP-initiated SSO to the SP. This is not covered by the SAML v2.0 specification and therefore the format of the URL including the parameter name etc is not standardized.
I suggest double checking with the IdP to see whether they do support SP-initiated SSO as per the SAML specification. Perhaps they simply haven't enabled this support. If they don't then you're only option is to use this non-standardized approach.
I'm working on a research about some new usage of SSO. Basically I'm trying to find way how to intercept SAML Request which is sent from Service Provider to Identity Provider with some kind of IdP proxy or 3rd party service, which will hold the SAML Request and will provide some additional functionality to users. The desired process could look like this:
User invokes SAML request from SP - click Login button for example
User is redirected to the 3rd party service, where is, for example, small survey(this is theoretical example)
After submitting the survey, user is redirected to the IdP and should continue with login
I have quite good experience with SimpleSAMLphp and configuring federation. But I my attempts to find some useful information about this kind of interception have failed. I add a super basic picture of the solution.(please don't laugh:) )
Does SAML support any kind of this processing? I'm open for discussion. I was also thinking to intercept the SAML after user signs in on IdP(to have redirection from IdP to 3rd part service proxy and then to SP)
Thank you for advices and your thoughts; hopefully, it's not totally stupid question
EDIT: During my research I came across technology/approach which is called IDP Proxy. Do you think that is feasible for my purpose? Basically, a SAML IdP Proxy is a bridge or gateway between a federation of SAML IdPs and a federation of SAML SPs. More about it for example here
I don't think this is possible, it's simply beyond the protocol. The SP provides a service, the IdP is responsible for user authentication. There seems to be no place for a 3rd party service between the two.
I guess you control (at least) either the SP or the IdP. Try to implement your survey (or whatever) at the provider you control.
As an alternative, you could try to implement your own IdP including a survey (or whatever) that uses the original IdP for authentication.
I'm implementing a SSO solution with SAML using OpenAM. I'm a very beginner on theses technologies and I need some clarifications.
My progress
For the moment, I have installed a Tomcat hosting OpenAM as an IdP.
Another Tomcat fits as my SP. The WebAgent is installed on it. When trying to reach a protected part of the SP, I am redirected to the IdP logging page. Once my credentials entered, I am finally redirected to the resource. That seems to work well.
My questions
My architecture is just based on a simple SSO, doesn't it ?
How do I activate the SAMLv2 ?
Does OpenAM have to be install on all servers in the circle of trust to allow SAML ? I mean, it seems natural on the IdP, but do I need to put and configure the opensso.war on the SPs ?
The choosen scenario is IdP-Initiated SSO. If the client reaches the IdP Authenticate WS, will it have the SAML assertion ?
Thanks in advance
When using agents, you are actually relying on a more proprietary SSO and not SAML. To be precise: Liberty ID-FF messages wrapped in SAML 1.1
The web agents will never talk using SAMLv2, so you will need to have some sort of SAML SP implementation (Java fedlet/.NET fedlet/SimpleSAMLPHP/Shibboleth SP/etc). To enable SAMLv2 federation you may as well follow the documentation ( http://docs.forgerock.org/en/openam/10.0.0/admin-guide/index.html#chap-federation )
If Authenticate WS means /openam/identity/authenticate REST/JAX-WS endpoint, then the answer is no, but if you correctly initiate a SAMLv2 login on the IdP (by using the idpssoinit endpoint), then the assertion will be presented to the SP, where the SP implementation can perform the necessary validations and extract the actual data out of the assertion.