I"m going to make SSO function by SAML2.0.
And I'm searching what item to be verified in response & assertion of SAMLResponse.
But there is no clear answer and suggestion.
I just read 4.1.4.3 Message Processing Rules, but not sure which items they are.
https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Thanks in advance.
You can use the SAML Response with Signed Assertion here to see what's in a typical one.
If you want someone to login to your app using SAML, your app first has to satisfy itself that the user is who they claim to be. It does that by verifying the SignedInfo on the Response. It uses the public key of the IdP to do that. Your app is the SP and should know how to find the public key of the Idp, from its SAML metadata. You can use the Issuer to get the IdP's entityID. Then, in AudienceRestriction, make sure the Response is intended for your app.
Once the basic verification passes, you can use the AttributeStatement to create an account for the user. The Attributes you need for that are in there.
So it's essentially a two part process. In the first part, you make sure the Response is valid, comes from the expected IdP and is intended for your app.
The second part is using the Attributes to manage an account for the user in your app.
There are various refinements such as NotBefore and NotOnOrAfter for Attribute values but those are the basic steps.
When initiating a SAML authentication request (from the Service Provider), is there any way to give the Identity Provider the username/email address to set as a default on login screen? I'd like that username to be added in the IdP's username box.
Using SAML 2.0 with OneLogin
I understand this can be done with the information within the AuthnRequest, but I cannot see any way of being able to modify that data.
is there any way to give the Identity Provider the username/email address to set as a default on login screen?
As far as I know, there is no standard way to indicate required attributes as part of a SAML authentication request sent by the SP. If you know this capability exists in the SAML specification, please share a link.
And even so, if hypothetically there was a way to ask for attributes in the authentication requests, that would only suggest to the IdP to consider sending and releasing those attributes back to the app; not that the attribute should be used in the login process/forms. That feature, is entirely implementation specific and depends on your choice of the SAML2 identity provider.
Problem: an SP site xyz.com/A gets a request for a resource xyz.com/B requiring authentication. A SAML request with relay_state=xyz.com/B gets sent to the iDP. The user gets redirected to the iDP site through SAML/SSO then onto idp.com.
I want to implement a link that allows the user to cancel his request for xyz.com/B and simply return him back to where he was browsing at xyz.com/A. Because there was a SAML redirect, I can't use the referer header at idp.com to find out where the user came from. Ideally I want to send the returnURL=xyz.com/A inside my SAML request.
So the question is is there such a way?
Thanks
I'm not aware of a standard SAML way you could achieve this. You would likely need to rely on custom extensions (such as additional query string parameters) to tell the IdP where to go on cancel.
Alternatively (and not so elegant - but practical) you could use JavaScript to send the user back a couple steps in the history? E.g.:
window.history.go(-2)
The IDP can return SAML response to SP. In the SAML response, you can use Status element to indicate that the user has cancelled the authentication process. As the top-level status code, you can use urn:oasis:names:tc:SAML:2.0:Responder. You can use your own status code as the the second-level status code.
I am working on handling LogOutRequest from a replying party on the STS side.
I can parse LogoutRequest, delete the cookie and generate a LogoutResponse.
The problem is where to send the LogoutResponse, I did not find the information about reply url.
Any ideas?
SingleLogoutService information is defined as part of the SAML 2.0 metadata that partners would exchange during setup. That would tell you where the Single Logout handlers are, and for which binding. I don't believe this information is typically populated in the logout request messages themselves.
Usually you get that info in the Issuer element of the request.
Hope it helps,
Luis
I've implemented my Service Provider and Identify Provider following the SAML Profile for Web SSO using HTTP POST Protocol Binding. However, I am a bit confused as to how the Identity Provider will provide an <AuthnStatement> if the HTTP POST coming from the Service Provider is not tied to a session on the Identity Provider.
Could someone enlighten me how one would be able to do this?
The other approach I could use is the HTTP Redirect Binding, but that requires User-Agent intervention (i.e., the browser), often using the User-Agent simply as a pass-thru intermediary to faciliate the Request-Response message exchange. I'd rather use HTTP POST for this reason, because the message exchange occurs server-side, so the user sees nothing happening on their screen.
However, using HTTP Redirect makes more sense to me with respect to how I'd be able to tie a session to a request. Since the HTTP Redirect is facilitated via a User-Agent, the request to the IdP will have a session (if previously authenticated). What I don't get though is how to send an <AuthnRequest> on a HTTP Redirect. Answered by JST
So I'm a bit confused and would love to hear what other people are doing. Here are my questions again:
Using the HTTP POST Protocol Binding with the IsPassive option the <AuthnRequest>, how do I tie a request made by the Service Provider to a session on the Identity Provider? In other words, how does the Identity Provider know who is making the request if the POST is coming from the Service Provider which is technically an anonymous session?
Using the HTTP Redirect Protocol Binding, how do I send an <AuthnRequest> to the Identity Provider if I am using a HTTP Redirect? Answered by JST
UPDATE
Sorry for the confusion if I was unclear in my explanation above. I am implementing both the IdP and SP (via a plugin). The IdP is an existing application for which I want the SP (a third-party system) to use for authentication (i.e., Web SSO). I am developing a simple PoC at the moment. The SP is actually a third-party Spring application for which I am developing a plugin to perform the SAML operations.
I should have mentioned that I am trying to do this using the IsPassive option, that meaning the User-Agent doesn't come into play during the message exchange. It is simply the catalyst that gets the SAML-party started. Right? With that in mind, given that the user is anonymous at Step 1, what does the SP send to the IdP to allow the IdP figure out whether the user is already authenticated? Because of IsPassive, the HTTP POST isn't sent via the User-Agent
UPDATE
Question 1 Revised: How does the IdP resolve the Principal when the AuthnRequset is sent with the IsPassive option on?
Straight from the SAML 2.0 Profiles document, page 15, lines 417 to 419:
In step 4, the principal is identified
by the identity provide by some means
outside the scope of this profile.
What I'm really after is an explanation how to implement some means.
The thing to keep in mind is that there's no connection between a session on the IdP and a session on the SP. They don't know about each other, and communicate only through the SAML messages. The general steps for SP-initiated SAML SSO are:
Anonymous user visits resource (page) at SP.
SP identifies that user needs to be authenticated at IdP.
SP constructs AuthnRequest and sends to IdP.
IdP does some sort of authentication, constructs SAML Response and sends to SP.
SP validates Response and, if valid, does whatever is necessary to identify user at SP and get them to originally requested resource.
Yes, there does need to be some way to connect the SP's AuthnRequest to the IdP's Response. That's covered by the SAML spec: the SP's AuthnRequest includes an ID value, and the corresponding response from the IdP MUST include an InResponseTo attribute (on its SubjectConfirmationData element) with that ID value. The Authentication Request Protocol also allows the SP to pass a RelayState parameter to the IdP, which the IdP is then REQUIRED to pass along unchanged with the SAML Response. You (in the SP role) can use that RelayState value to capture state information allowing the user to be relayed to the originally requested resource.
That implies that when you implement an SP, you'll need some mechanism for recording ID and RelayState values, and your Response processing needs to validate InResponseTo and RelayState values it receives. How you choose to create and interpret RelayState values is up to you, but keep in mind that there is a length limit. (We use random GUID values corresponding to locally saved state data, which has the extra advantage of not giving any hint of meaning to the RelayState values.)
How does the IdP know who is making the request? The AuthnRequest must include an Issuer element that identifies the SP. It might also contain an AssertionConsumerServiceURL (the URL to which the Response is to be sent), or the IdP may have a local mapping of the Issuer to the proper URL.
How do you send an AuthnRequest using HTTP Redirect? The only difference between AuthnRequest sent using POST vs. Redirect, besides using GET rather than POST, is that the AuthnRequest XML has to get compressed (using the DEFLATE encoding).
Hope that answers most of your questions.
John,
I might suggest taking a step back and doing some more research before you decide to write your own SAML IDP/SP Implementation. You appear to be mixing Bindings with Profiles, Unsolicited vs Solicited Web SSO as well as the fact that SAML requires that the User Agent (aka Browser) is the bearer of almost all the messages between the IDP and SP. There is also a ton of info in the spec that will will have to implement to ensure your solution is actually secure.
I would suggest starting with our SAML Knowledge Base and then moving on to the OASIS SAML 2.0 Technical Overview for information on these flows.
Alternatively, if you decide to go best-of-breed you can check out our PingFederate product which can enable ALL the SAML IDP/SP use cases for you in < a day.
Hope this helps -
Ian
Unlike Ian, I am not associated with a company producing SAML-related products. However, I'd give somewhat similar advice: step back and identify why you are implementing SP or IdP. Are you really acting as both SP and IdP, or are you really just one or the other? If you're implementing/acting as IdP only, then it's fairly likely that a product like PingFederate or something similar offers all you need through configuration rather than requiring you to write custom code. If you're implementing SP, then such a product MAY be able to help you out, but it depends to a large extent on the characteristics of the system you're integrating it into. I am speaking as a developer who has done both IdP and SP implementations, and evaluated several tools before determining that because of our specific system, clients, and requirements, a custom implementation was our best option. It's been in place for over a year, with several clients using it (including some using varying commercial IdP tools).
If you can identify your use cases in terms of SAML profiles/bindings, then you'll be better equipped to make a buy-vs-build decision.