Sunday, August 31, 2014

Spring Security SAML Project, Gradle Problems

Gradle scripts provided by Spring Security SAML project, https://github.com/spring-projects/spring-security-saml when executed fail to run as expected.  Based on some random posts on the web replaced the dependencies
from:
        classpath("org.springframework.build.gradle:propdeps-plugin:0.0.3")
        classpath("org.springframework.build.gradle:docbook-reference-plugin:0.2.4")
to:
        classpath("org.springframework.build.gradle:propdeps-plugin:0.0.7")
        classpath("org.springframework.build.gradle:docbook-reference-plugin:0.2.7")
 
in the file build.gradle.  After making the above changes, was able to run gradle eclipse to create eclipse project, and gradle clean build to build from the command prompt.

Thursday, August 28, 2014

OpenAM, Spring Security SAML Integration

Summary

Springteam has provided spring-security-project with all required build files.  Based on the spring-security-saml project, Single Sign On using OepnAM was demonstrated relatively easy.  Shared here are the configuration changes required to demonstrate the SSO using OpenAM, and Spring-security-saml project.

Environment

 The demonstration was done using OpenAM11.x deployed on Tomcat, and the web application from spring-security-saml projected deployed on Tomcat as shown below:

 

Integration Breakdown

 Following are the various steps involved in the integration:
  1. spring-security-saml source code
  2. Configure IdP metadata
  3. Configure truststore
  4. Compile source code
  5. Generate SP’s metadata
  6. Register Remote Service Provider
  7. Validate Spring SAML secuirty

spring-security-saml source code

Source code is available on github. Url for the project is:
https://github.com/spring-projects/spring-security-saml.  Download source code, and unzip the file to a directory of the user’s choice.  Files of interest and, the configuration files which have to be modified are:
  1. spring-security-saml-master\sample\src\main\resources\metadata\idp.xml
  2. spring-security-saml-master\sample\src\main\resources\security\samlKeystore.jks
  3. spring-security-saml-master\sample\src\main\webapp\WEB-INF\securityContext.xml

Configure Identity Provider’s Metadata

Application’s configuration file is securityContext.xml as listed above.  The source code contains a sample Identity Provider’s metadata file, idp.xml as listed above, and is configured in securityContext.xml as shown below:
 <bean id="metadata" class="org.springframework.security.saml.metadata.CachingMetadataManager">
                <bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
                        <bean class="org.opensaml.saml2.metadata.provider.ResourceBackedMetadataProvider">
                                <bean class="org.opensaml.util.resource.ClasspathResource">
                                    <constructor-arg value="/metadata/idp.xml"/>
Either Spring configuration file securityContext.xml has to be modified to reflect the actual name of the Identity Provider’s metadata file, or replace idp.xml with the actual metadata of the Identity Provider.
As OpenAM is currently used as the Identity Provider, metadata retrieval from OpenAM only is mentioned.   Identity Provider metadata can be downloaded from OpenAM’s url:
https://idp.saml.org/openam/saml2/jsp/exportmetadata.jsp?entityid=<Entity Id used for>

Configure Truststore

Similar to configuring Identity Provider’s metadata, application’s truststore is configured by securityContext.xml as shown below:
<bean id="keyManager" class="org.springframework.security.saml.key.JKSKeyManager">
        <constructor-arg value="classpath:security/samlKeystore.jks"/>
        <constructor-arg type="java.lang.String" value="nalle123"/>
        <constructor-arg>
            <map>
                <entry key="apollo" value="nalle123"/>
            </map>
        </constructor-arg>
        <constructor-arg type="java.lang.String" value="apollo"/>
    </bean>
Truststore used by the application should be able to decrypt the encrypted response received from the Identity Provider, and requires that Identity Provider’s public certificate be added to the truststore.  Either change the truststore location and password to reflect a new truststore containing Identity Provider’s public certificate as against the truststore provided within the downloaded code, or just add Identity Provider’s public certificate to samlKeyStore.jks as described above.

Compile Source code

Downloaded source code contains gradle build file, and mvn pom files for compilation.  As of this writing compilation with gradle fails with the following messages:
FAILURE: Build failed with an exception.
* Where:
Build file '<path to downloaded file>\spring-security-saml-master\build.gradle' line: 22
* What went wrong:
A problem occurred evaluating root project 'spring-security-saml'.
> java.lang.String cannot be cast to org.gradle.api.artifacts.Configuration
While gradle build failed with exception, compilation with Maven resulted in a successful build, and a deployable war file spring-security-saml-master\sample\target\spring-security-saml2-sample.war.  To shorten the length of the context root of the deployed application, rename the file to a name of user’s choice, say spring.war.  Deploy the war file in a servlet container.

Generate Service Provider’s metadata

Metadata for the secured application can be downloaded from the unsecured url: http://sp.saml.org/<context root>/saml/metadata.

Register Remote Service Provider

Login to OpenAM’s admin console, and register remote service provider by using service provider’s metadata downloaded above.

Validate Spring SAML Security

By default the root directory of the web application is secured, and require authentication.  Try to access the root directory of the application, http://sp.saml.org/<context root>/.  A page requesting IdP selection is displayed.  Select the IdP from the available options, and click on submit.  The user would be redirected to the authentication page as configured on OpenAM.  After providing valid credentials, the user is successfully authenticated on the Identity Provider, and the user is redirected to the default page of the application, index.jsp which lists various SAML attributes demonstrating SAML.
Spring SAML security validation was done using X509, Username and Password, and Basic Authentication modules supported by OpenAM.

Summary

Overall the integration experience was pleasant, and great appreciation goes to the spring team for the spring-security-saml project.

Wednesday, August 6, 2014

Open AM-Certificate Authentication-User has no profile in this organization

OpenAM

Certificate Authentication


Setting up OpenAM for certificate authentication was explained in detail at the URL: http://blog.profiq.cz/2012/05/24/certification-based-authentication-with-openam-10-and-tomcat-7/
Following the steps detailed in this article an IdP using OpenAM running in Tomcat was set up.  While the setup was straight forward, encountered a cryptic message User has no profile in this organization, while testing. With self signed certificate, was able to get rid of this message by adding a user with the CN present in the certificate.
Later Tomcat's truststore was replaced with CA root certificate.  The same cryptic message User has no profile in this organization, resurfaced again.  Google search pointed to several discussions which did not help including creating a separate realm.  After scouring OpenAM's debug files, in combination with the public certificate revealed that the certificate had two CNs in the certicate's DN one corresponding to the user's name, and the other as Users.  Open AM's default implementation of Certificate field to access user profile was CN.  Since the cert had two CNs, CN was replaced by the user identified as Users, which does not exist, and should not exist within OpenAM's realm.  Subject DN is one of the options provided by OpenAM for Certificate Field to Access User Profile.  Changed The option to subject DN, created a user within OpenAM's realm with CN presented by the certificate.  IdP processed the request for SAML authentication successfully, and the Service Provider was able to process the SAML assertion.