I want to know if there is a way to only use GET type requests in the exchanges with the IDP. I don't want to use a POST method to exchange with the IDP. Is there a parameter that allows this ?
Take a look at section two of the "Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0" specification.
The SAML authn request sent to the IdP may be sent using HTTP-Redirect, HTTP-Post or HTTP-Artifact. The SAML response sent to the SP may be sent using using HTTP-Post or HTTP-Artifact. HTTP-Artifact is rarely used which means the IdP will send the SAML response using HTTP-Post.
There isn't an option to send the SAML response using an HTTP GET. The reason for this is that SAML responses are generally too long to be encoded as query string parameters.
Related
I am implementing SSO using an external Identity provider to which I do not have access yet.
The IDP metadata IDPSSODescriptor has one SingleSignOnService tag with a binding value of: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
Does this imply that I cannot initiate an authentication request to the SingleSignOnService location with a GET request or that the service will respond with a POST request?
It means that the protocol endpoints that you will interact with expect POST interaction from the client (typically a browser). This is required these days for sending the assertion from the IdP to SP, but Redirect is usually acceptable in the case of the SP sending an AuthnRequest to the IdP.
I am trying to understand SSO using SAML. I have come across the RelayState parameter and am very confused exactly why it comes first in SSO to send encoded URLs? What exactly does it mean?
Please read the following from the Google Developer documentation:
Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner's SSO service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection
The original meaning of RelayState is that the SP can send some value to the IDP together with the AuthnRequest and then get it back. The SP can put whatever value it wants in the RelayState and the IDP should just echo it back in the response.
This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection
There is also another, de facto standard use for RelayState when using Idp-initiated log on. In that case, there is no incoming request from the SP, so there can be no state to be relayed back. Instead, the RelayState is used by the IDP to signal to the SP what URL the SP should redirect to after successful sign on. In the standard (Bindings 4.1.5) it is stated that RelayState "MAY be the URL of a resource at the service provider."
It looks like Google is using RelayState for the target URL even on SP-initiated sign on, which is perfectly fine. But the IDP should, as the documentation says, just relay it back.
RelayState is an identifier for the resource at the SP that the IDP will redirect the user to (after successful login). It is a way to make the process of SSO more transient to the user because they are redirected again to the same page they originally requested at the SP.
As per official SAML document,
Some bindings define a "RelayState" mechanism for preserving and conveying state information. When
such a mechanism is used in conveying a request message as the initial step of a SAML protocol, it
places requirements on the selection and use of the binding subsequently used to convey the response.
Namely, if a SAML request message is accompanied by RelayState data, then the SAML responder
MUST return its SAML protocol response using a binding that also supports a RelayState mechanism, and
it MUST place the exact RelayState data it received with the request into the corresponding RelayState
parameter in the response.
This below flow diagram may help you step by step. ACS URL and relayState both are different. relayState gives you one more info/url to handle where exactly user want to go. more details
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.
Scenario:
Browser(User) requests resource from Service Provider (SP).
SP Redirects (with SAML Request) to Identity Provider (IdP).
Since it is first login, User gives the (IdP) his/her valid credentials.
IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
I have two questions:
A. In Step 4, does the Browser store or cache the SAML Response and/or SAML token?
B. If yes, what kind of things (attributes? timeouts? protocols?) prevent me from taking that stored SAML token. Then coping it over to another computer (with a new session) and using that token to Login to the same SP?
The answer is "sort of" re caching. In your scenario, the Response will be sent via POST to the Service Provider from the browser. So the browser can "cache" the POST data that contains the SAML Response. So, just like any other POST event in browsers, if the user were to use the back button enough times after logging into the SP to get back to the POST event, the POST data could be resent to the SP.
There are a few things that help keep the Response from being hijacked -
Use of HTTPS between all parties
SP enforcement of NotBefore & NotOnOrAfter attributes
SP enforcement of one time use criteria (the SP must ensure that Response is not re-used during its validity period. If the message is received outside the validity window, then the SP should discard the message)
The IDP usually stores a session cookie on the client browser identifying the SAML session. The theft of this session cookie is probably no more protected then any other session cookie.
Using HTTPS in communication between SP and IDP will provide a great deal of protection from session hijacking.
For question A, it probably depends on the browser that you use.
For question B, there are several mechanisms that prevent the SAML response from being reused:
SubjectConfirmationData has attribute NotBefore and NotOnOrAfter that specify the time frame that the SAML assertion is valid. Thus, the SAML assertion cannot be used outside of this time frame.
SubjectConfirmationData has attribute InResponseTo that specifies the SAML request for which the SAML assertion is issued. Thus, the SAML assertion cannot be used for other SAML request.
SP must ensure that the SAML assertion is not replayed by maintaining a set of used SAML assertion.
You can read Section 4.1.4.3 and 4.1.4.5 of SAML Profiles specification.
I know this old, but the answer is yes the browser stores the SAML Token as a Cookie. (Typically) You can see it in your Browser's Cookie list, through various traffic/session inspectors like Fiddler, SAML Tracer on FF etc.
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.