I am new to SAML. Could you please explain in plain English what is SAML profile and binding and provide a couple of examples.
As nrathus points out in his comment, Wikipedia's entry on SAML is a pretty good place to start.
The SAML 2.0 entry, though, delves further into the version you're most likely to use.
Having said that, my answer is this:
Bindings - these are essentially the technical method of a connection. Are we expecting the browser to POST the assertion (HTTP POST Binding)? Or should service provider be retrieving an artifact from the identity provider over SOAP (HTTP Artifact Binding)?
Profiles on the other hand, basically define a set of things that you want to do. Browser SSO? SLO? IdP Discovery?
In a nutshell, Profiles are what you do, and bindings are how you do it.
Related
BACKGROUND:
My company is acting as the Service Provider to our clients that are the IDP. We use OpenAM, but our clients use ADFS or Shibboleth. We exchange metadata files for establishing federations, not URLS. A client asked why we require an AuthnContext class schema (specifically PasswordProtectedTransport), and not only do we not know why, we don't know how to change it or what that would mean.
QUESTION:
What is the functional difference between using "PasswordProtectedTransport" vs "unspecified" for the AuthnContextClassRef in a SAML2 assertion?
We currently use PasswordProtectedTransport amongst all our clients, but no one at my company can tell me why we require this. If we remove it, the federation stops working with a 500 error and a "NoAuthnContext" in the SAML trace. We also don't understand that, as I was led to believe from SAML documentation that having a schema is optional for the authentication. Even so, I saw no explanation anywhere of what the implications of using "unspecified" would be.
I can’t find any thorough explanation or discussion anywhere about this topic and was hoping someone could elaborate for me, as I am struggling to find light on this.
RequestedAuthnContext in a request is a mean for a SP to ask the IDP to authenticate the user with a specific authentication mechanism.
For example, if you specify PasswordProtectedTransport in your request, the IDP knows it has to authenticate the user through login/password, protected by SSL/TLS.
The IDP says in its response which mechanism it used to authenticate the user through AuthnContextClassRef.
RequestedAuthnContext in a request is optional, but AuthnContextClassRef in the assertion is mandatory as specified by the SAML schema (hence the 500 error you encountered).
Basically, the unspecified URN is used by the IDP to say "I don't want to tell you how I identified the user".
As a SP, you have the choice to accept that answer or reject it, if you want to ensure that the user is authenticated with a secure mechanism.
I am going to implement ServiceProvider part using SAML 2.0 WebSSO profile. According to the SAML specification, the two supported flows are SP initiated and IDP initiated. I want to implement only IDP initiated flow because of time constraints. Will it work? or is it required to implement both the flows?
I dont want to generate any metadata for my SP. Can I still register my SP at IDP without providing any metadata by giving only default Assertion Consumer Service URL?
Short answer is yes it will work but... and yes if it is supported.
About implementing the IDP init SSO. It will work with only IDP init SSO if the IDP supports it. But your implementation will not be conformant with the SAML standard.
SAML does not require one to use metadata, this is just a good way to transport configuration data. If this will work depends if your IDP can be configured without using metadata. I have seen many that can do this.
Agree with #Stefan - no, you don't have to implement both flows.
SAML has many options - generally there is not enough information in the Assertion Consumer Service to fully configure e.g. certificates, public keys, supported endpoints etc.
But if the IDP allows this, you can do it manually - you just have to provide all the bits and pieces. And you'll have to do this again when the certificate expires etc. Metadata makes this all easier.
Java or .NET? If .NET, there are classes available to generate the metadata. Not sure for Java but would be surprised if there aren't.
Im a newbie to the SSO concept and SAML.My requirement is in detail below :
having a common login page. End user will be logged in using credentials;
once the user is logged in, he will be redirected to my application. From there, we will have links to other application.
Here, my application is working as Service Provider.
My question is : as SP, how could I generate SAML 2.0 request to other applications from mine?
How to check whether my application supports SAML 2.0?(its java based).
To conclude, how to generate and send/receive digital signatures through SAML 2.0?
Can anyone please explain me the flow first then direct me to some link?
Does your application support SSO? If not, it probably doesn't support SAML.
You need a client side SAML stack. - examples here.
The commercial implementations in particular have lots of example code.
For Java, look at the Spring SAML extension.
Also, get as much information as you can re. the IDP because that will determine what SAML protocols and bindings you need to implement.
After reading some articles and references, I found that they practically illustrate what is SAML, what components it contains, how it works. Some good links as follows:
Good documentation about Shibboleth and SAML?
What's the difference between ADFS, WIF, WS Federation, SAML, and STS?
http://en.wikipedia.org/wiki/SAML
http://saml.xml.org/wiki/saml-introduction
https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
...
I, however, still feel confused about it: why say it is secure? In my view, in short, SAML is just a "formated" XML representation. It is a language or mechanism for the exchanging the figures on the information high way. I cannot find that it is secure, it just provide a negotiation or standard way for exchanging information only. I don't know whether my understanding is correct or not. Why SAML contains "security" still confuse me.
I think the piece that you are missing after all that reading is how SAML requires the use of the XML DSIG and XML ENC specs to ensure message integrity and confidentiality. While standardized message formats and common name identifiers make sharing identity information much easier between parties, it is these two security components (when implemented properly) that allow SAML to be confidently adopted by Enterprises, Governments and Cloud Service Providers to exchange identity information.
HTH - Ian
To make it secure we can digitaly sign the response with our private key and share the certificate with the Service provider.In this way it can provide the security against fake IdP and "Man in the middle" attack (MITM).
Apart from that it is always recommended to have this transaction to be HTTP over SSL.
And last but not the least you can also use persistent/transient pseudonyms to exchange informaton between IdP and SP.
Yes, SAML is an XML based language for information exchange as the name Security Assertion Markup Language means. Why SAML is called a security markup language is because this language is specifically defined to exchange security and identity related information such as authorization information, authentication information etc. Due to this capability of the language there are many security protocols and profiles defined around SAML such as SSO profile, Web Service Profile 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.