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.
Related
I am looking to do IdP Discovery and i need to do this with Pingfederate Software. End Goal here is customers will request access to a resource. Then get redirected to an IdP where they see a logon form ... input their email address and then depending on their email domain they get redirected to another IdP where authentication will take place. SAML Assertion will get posted back and the customer can then access the application.
I know pingfederate has persistent cookie etc but i dont think this will work well. Has anyone tried IdP Discovery in Pingfederate?
The PingFederate Standard IdP Discovery is a cookie based mechanism that identifies the IdP, or matching of entityID to IdP. We have used the OOTB PingFederate capability and found it does work well for certain use cases and business requirements for user experience. This blog describes alternative approaches that are popular within industry to accomplish IdP Discovery. We have found that most service providers tend to use one of the forms of IdP Discovery described in the blog. The real driver for the implementation approach is business requirements for user experience. For PingFederate, if you choose not to use the out of the box cookie mechanism, then you will need to implement one of the other design patterns. I do know that there are Ping System Integration partners that have expertise and implementations of each of the design patterns described.
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.
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.
Our app has SAML2 SSO integration with 3 different (Shibboleth) IdP's. We are trying to add a 4th (also Shibboleth), but running into some issues, because our app expects all SSO responses to be verifiably signed. These other 3 are signing their responses, but the 4th is not, and is hesitant to add a custom config to enforce signing for our app.
Technically I could modify our app to accept unsigned SSO responses, but I am wondering whether or not I should. What are the pitfalls of allowing unsigned SSO responses? Is there any security vulnerability?
Is there any Shibboleth (or other SAML2 SSO) documentation that recommends signing responses as a best practice?
The only requirement for the IdP following the SAML 2.0 spec is to digitally sign the Assertion (see http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf - section 4.1.3.5). That is enough to tell if the SSO operation from an IdP should be trusted by SP that has federated with it.
Signing the outer Response is optional. There are some security benefits to it, such as preventing Message Insertion or Modification (see sections 6.1.3/6.1.5 in http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf) - but in practice it's often omitted in lieu of relying on SSL/TLS.
The whole point of signing the response is to prove that they actually do come from the issuer. Otherwise a "man in the middle" could change the attributes e.g. to give themselves access to an application.
ADFS v2.0 using SAML by default signs all response tokens. There's no way to turn this off.