SAML2 IDP initiated SSO - implementation help

[reyabreu]

I'm new to Spring, SAML & Security dev in general. I have been tasked with integration of a Spring Web App I'm developing, in an SAML2 IDP initiated SSO use case. In the last few weeks I have plunged heads-on to learning all this stuff and successfully configured the sample application in Tomcat 6, using ssocircle as IDP with HTTP-POST bindings and default selection of IDP - so I'm feeling more confident now.

However, I'd appreciate your guidance with my use case - just showing me the ropes will be much help.

A third-party that supports IDP initiated federation only, provides links to my app acting as SP. SP will receive SAML responses via HTTP-POST. Authentication assertions will be signed by a Verisign signed certificate - in p7b format. No authorization (user permissions) information will be provided from the IDP side - it will only authenticate. IDP will not participate in any session management and no Single Signout process will be available.

My app-SP will grant access/authorizations for logged on users, and provide local sign out only.

Questions:
1.- How do I constrain SAML extension to only accept IDP initiated SSO?
2.- How do I map IDP authenticated users to a repository of SP maintained users?
3.- How do I check Verisign CRL (certification revocation list) and certificate expiration before verifying signature?
4.- I'll need to validate response element contents (Issuer, Audience, Element, AuthnContextClassRef) against fixed values. How to do this?
5.-How do I prevent message replay attacks in SAML extension?

And finally, but most importantly:

How does one test this kind of scenario in a local dev environment??

Thanks!

[NicoTexas]

Hi,

I can't answer the Spring specific questions (I wrote my own implementation on top of openSaml).
But I can help you to setup the local environment.
What I did is, install http://simplesamlphp.org/ on my local apache2 server.

From there what you want to do is setup an idp in simplesamlphp. It's pretty easy.
Just follow the documentation here :
http://simplesamlphp.org/docs/stable/simplesamlphp-idp
For the authentication source I suggest you to go with the simple user/password example

Once you're done, you can do an idp initiated sso using that kind of url
https://localhost/simplesaml/saml2/i...ntityid=myspid

where "myspid" is the entity ID of your service provider.

good luck !

[vsch]

1.
You can disable the SAMLEntryPoint by not including it in the security:http element and remove the security:filter-chain with pattern /saml/login. That way no user of your SP will be able to initialize SSO. To assure that global logout never gets invoked you can e.g. replace bean SAMLLogoutFilter with org.springframework.security.web.authentication.lo gout.LogoutFilter.

2.
You can implement interface SAMLUserDetailsService which has access to complete content of the data received from IDP including NameID. As part of the implementation you return your own object representing your user (typically an instance of UserDetails interface). The implementation is then plugged to the samlAuthenticationProvider bean. More details can be found in chapter 4.10 of the SAML Extension manual.

3.
Certificate expiration is validated automatically for you once you enable PKIX security profile (see chapter 4.6 in the manual). You can customize trust evaluation (including adding of CRLs) by overriding method populateTrustEngine in the SAMLContextProviderImpl.

4.
The values are validated for you according to the SAML 2.0 standard (this includes, among many other, issuer and audience). If you'd like some additional validation, e.g. the AuthnContextClassRef, you can do so by overriding methods in the WebSSOProfileConsumerImpl class, e.g. method verifyAuthnContext or processAdditionalData.

5.
Preventing replays is more difficult with IDP-initialized SSO and HTTP-POST, as there's neither InResponseTo field available nor an Artifact which can only be retrieved once. Similar question has been answered here http://forum.springsource.org/showth...-SAML-Response . If you'd like additional protection you can add your custom processing logic which remembers previous message IDs and rejects messages with the repeated ID in the same place as in 4.

There are also other options for testing of this on top of what Nico's already mentioned - e.g. Shibboleth, OpenAM. But getting a test account with your IDP is typically the best way.

Hope this helps,
Vladi

[reyabreu]

Hello Nico, thanks for your reply! I've been looking at OpenAM until now, but will give your suggestion a shot too.

[reyabreu]

Hi Vladimir, your answer is very helpful. Thanks for your guidance and kudos for your excellent work on this extension.