I am new to SAML. I want to know how to secure the SAML request and response communication between Service Provider and Identity Provider? I have seen an element digest in SAML response message examples. Can that be helpful to solve my doubt. How is that implemented?
Are you creating or validating signatures? Here are the (really) basic steps --
canonicalization of XML
create digest value, typically SHA1 (but could be SHA256 amongst others)
base64 encode it
SAML requires the XML Signature Syntax and Processing specification (http://www.w3.org/TR/xmldsig-core/) for signed messages. If you don't do this properly, you will have interop issues with other 3rd Party partners since they won't be able to validate your signed messages (resulting in invalid messages) or you will not be able to validate their messages.
If you don't understand the crypto in SAML, you're probably better off using a commercial product (like products from Ping Identity [Note:I do work for Ping]) to 1) speed up your deployment and more importantly 2) ensure that you are secure and compliant.
Related
My sectoken is authorized but I don't know how to formulate a URL so that I can bypass the WSO2 IS sign-in page (login.do).
I read online it can be passed through a link in this format:
localhost:9443/samlsso?SAMLRequest=[SAMLRequest]§oken=[SECTOKEN]
I'm just not sure what to put in for [SAMLRequest].
As for the answer, you may try to use OneLogin PHP module to generate a SAML Request.
Here is an example SAML Authn Request however you may need to change the issuer, destination, AssertionConsumerURL, and issue timestamp.
Please note there's difference when sending SAML Request as GET and POST. GET (Redirect-Binding) uses deflate and encode, signature is a separate request parameter, POST (POST-Binding) uses signed XML and only encoded XML, not deflated.
SAML is great protocol (very well designed and secure when implemented properly), but it may look difficult for people who hasn't use it before, it may require using external libraries to properly create requests and validate responses. That's why you may be as well looking for option which would may make your life simpler, such as using WSO2IS for SSO (single-sign-on) e.g. using simpleSAMLphp or direct OAuth authorization request.
I'm working with a customer who has built a home-grown engine to generate SAML assertions. We are using ForumSentry to validate the assertion, but the digest is failing to validate. We already have a dozen other customers sending us SAML assertions, for web SSO, perfectly well, and I'm sure ForumSys have many 100's of customers for ForumSentry working perfectly well too.
I've spent many hours trying to understand exactly what the digest is made of and trying to find samples of XML which goes into the digest algorithm. I've failed and I would appreciate some help please.
It seems to me that the only data signed is the reference URI, and not all other the "parameters" of the assertion, such as the subject, issuer, etc. Is this correct / what don't I understand? What is the background to this? If correct, how is the other data protected from tampering?
Is there an assumption that Web SSO must be over HTTPS to protect the integrity of the entire assertion?
What data exactly forms the data that is signed? Could someone post an example please, both pre and post canonicalization of data that is signed.
Any other background info would be great.
SAML uses XML DSig for signing. When a SAML entity (an assertion, an entire Response, metadata etc...) is signed it is done by using specific algorithms in the XML Dsig suite.
The reference of the signature must point to the ID of the signed entity. For a signed assertion that is the ID attribute of the <assertion> node.
The canonicalization algorithm used must be Exclusive Canonicalization. This is nothing that affects the actual XML contents, it is an instruction to the XML parser used by the crypto library that makes sure that whitespace differences etc. won't affect the validity of the signed data.
XML DSig works in two steps:
First a hash is calculated for each reference in the signature. For SAML signing there should only be one reference to the ID attribute of the enclosing entity.
Then a cryptographic signature is calculated across the XML containing the hashes.
This means that a single signature can be used to verify the integrity of several pieces of XML, but in SAML that functionality is not used.
With each signature containing exactly one reference to the ID attribute of the signed entity, the entire entity is protected by the signature.
I'd suggest that you read the SAML core spec section 5.4 if you need more details on how the XML signature works with SAML.
I've seen a bunch of flow chart on how it is passed around between Identity Provider (IdP), Service Provider (SP), and Browser via Redirects. However it seems unnecessary to me right now, so i know i'm missing something.
Can someone provide me a use case where a SAML Artifact is required (or very useful) compared to not using one?
Thank you.
Typically, the intent of the artifact binding is to reduce the flow of SAML messages through the browser itself. This could be due to browser restrictions (browsers that have limits on query string / POST payload size) or no support for JavaScript (for auto-submitted forms), or even to improve the security model of how the SAML messages are transported. By using artifacts, sensitive data carried through the SAML Assertion / Attribute Statement is not passed through the browser, so it can be hidden from the end user or attackers between your site and the end user. This confidential data would only be directly resolved between sites through a back channel lookup.
Section 3.6.2 of the SAML 2.0 Bindings specs summarizes it best:
The HTTP Artifact binding is intended for cases in which the SAML
requester and responder need to communicate using an HTTP user agent
as an intermediary, but the intermediary's limitations preclude or
discourage the transmission of an entire message (or message exchange)
through it. This may be for technical reasons or because of a
reluctance to expose the message content to the intermediary (and if
the use of encryption is not practical). Note that because of the need
to subsequently resolve the artifact using another synchronous
binding, such as SOAP, a direct communication path must exist between
the SAML message sender and recipient in the reverse direction of the
artifact's transmission (the receiver of the message and artifact must
be able to send a request back to the artifact
issuer). The artifact issuer must also maintain state while the
artifact is pending, which has implications for load-balanced
environments.
Expanding on Scott T's answer, the SAML Artifact Profile was designed to improve security. To prevent a user from modifying it's SAML Assertion mid-traffic (such as changing Username, roles, etc), SAML 2.0 suggests that developers sign assertions via XML signatures. XML Signatures though are extremely vulnerable to XML wrapping attacks because of issues in every languages existing XML parsers. Visit https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-be to see XML wrapping attacks in action against SAML Assertions.
The SAML Artifact Profile solves this issue by creating a one-time use "artifact" that is passed to the Service Provider by the user (via redirect or post) rather then the SAML Assertion. When the Service Provider receives the one-time use artifact, it sends a SAML Artifact Resolve Request (containing the artifact) to the Identity Provider's Artifact Resolution Service (ARS). The ARS then responses with a SAML Artifact Response (containing the user's SAML Assertion) thereby preventing the SAML Assertion from ever being modified by the user as it is directly received by the Service Provider over a back channel.
A SAML message is transmitted from one entity to another either by value or by reference. A reference to a SAML message is called an artifact. The receiver of an artifact resolves the reference by sending a request directly to the issuer of the artifact, who then responds with the actual message referenced by the artifact.
Refer SAML 2.0,
Without the artifact there is no way to get to the actual message.
Note that this is only required when using HTTP Artifact Binding. (As opposed to the more common HTTP POST Binding which simple sends the SAML message).
Another reason for using HTTP Artifact binding is that you can use SSL to ensure SAML message integrity and confidentiality. The SAML requester and responder do not need to sign, validate, encrypt, and decrypt the SAML message.
it may be considered out of interest nowadays but the artifact profile is also useful if you have a low bandwidth between the user agent and sp & idp servers and a better bandwith between sp & idp. The (heavy) assertion does not circulate from the idp to the ua and from the ua to the sp and it may show better performance in certain circonstances.
I am using saml2.0 for sinlgle sign on(SSO). In all the examples I have seen in the internet, there is a tag in the response-digest. What is this digest? Is this necessary even when the connection is https?
Yes, when using SAML 2.0 and signed messages (HTTP Post requires digitally signed Responses), the DigestMethod and DigestValue are required and must be generated/validated per the XML Signature specification using Transform: Enveloped Signatures. If you don't properly sign/validate the message, what's to stop an attacker from intercepting the message and modifying its contents? SSL only protects the message in transit, not the contents of the message itself.
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.