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.
Related
Is it possible to configure a Relying Party in ADFS to send the SAML Response to a Destination URL while having the Recipient URL in the SubjectConfirmationData block be a different URL? I haven't seen anyway to configure those two to be different in the ADFS UI. Our use case is that we have a proxy we want to send the SAML Response through en-route to the service provider (us in this case) which is expecting the Recipient URL to be a certain value. We obviously can't manipulate that value in the SAML Response using the proxy itself since those responses are signed from the IDP.
I checked and there is no available way to configure the relying party in ADFS in the above way you have mentioned. URL must match the one that you specify in the Service provider ID field of the web server IDP configuration document.
I've implemented Identity Server 3 with SAML based on this example: https://github.com/Sustainsys/Saml2/tree/master/Samples/SampleIdentityServer3
Everything is working, but the SAML Identity Provider (DigiD) requires reauthentication. This is done by sending the SAML AuthnRequest again.
Does anyone know how the SAML AuthnRequest can be send again from Identity Server 3? I've tried to use refresh tokens, but this doesn't seem to trigger another SAML AuthnRequest.
There are two parts required here
Get IdentityServer3 initiate another authentication request with the Sustainsys.SAML2 module.
Optionally set the ForceAuthn flag in the created AuthnRequest to the SAML2 Idp, to instruct it to actually reauthenticate and not rely on an existing session (don't remember if the library supports it).
During SP-initiated SSO, the Authentication Request(AuthnRequest) can specify to which Assertion Consumer Service (ACS) the Security Assertion Markup Language(SAML) Response has to be sent in the AssertionConsumerURL.
Similarly in IDP initiated SSLO where should we send the SamlLogoutResponse to ?
In the logout request example I dont see AssertionConsumerURL. Do we have to send the response to what is specified in the destination parameter?
ACS and SLO (Single Logout) are different endpoints in SAML.
They are normally specified in the metadata.
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.
Method 1
Browser is directed to Service provider. Service provider checks whether there is any cookie set, If no then it redirects browser to Identity provider and Identity provider(IdP) validates user and redirect a ID to Service Provider(SP). SP takes that ID and set it as session cookie in browser and redirects user to service. Next time, if user asks for service again in same session the SP checks for cookie and redirects directly to service.
Method 2
Browser is directed to Service provider. Service provider redirects to IdP. IdP checks for its cookie and if cookie is not present,IdP authenticates user and set session cookie in browser. Redirects positive response to SP. SP redirects user to service. Next time user asks for the service within the session, Browser is directed to Service provider. Service provider redirects to IdP.IdP checks for its cookie and if it is present,it sends positive response to SP.
I am pretty sure that Guanxi implementation of Shibboleth (SAML2 profile) and almost sure that Shibboleth itself can be simplified to your "method 1".
You better check some of existing SAML2 profile implementations.
I don't believe either of those are valid SAML implementations. Usually in SAML identity information is communicated in a HTTP POST or through SOAP web service (see: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#SAML_2.0_bindings). Cookies are not used to 'authenticate' a user.
We have a web application that uses SAML 2.0 XML communicated in a HTTP POST to authenticate the user. Our customer's employees go through the identity provider on their side of the firewall to access our application.