Skip to content

SSO Using OpenAM SAML2

Jump to bottom
Giorgos Triantafyllidis edited this page Jan 31, 2017 · 1 revision

SSO Using OpenAM SAML2

Introduction

OpenWIS 4 may now use OpenAM as an SSO IdP. This feature was added as a PoC and will need further tweaking if intended for production use. The OpenAM IdP vresion used in the development and testing of thie feature was 12.0.

Configuration

This section will describe the necessary steps in order to correctly configure and deploy OpenWIS 4 with SAML SSO using OpenAM.

Step 1: OpenAM: Initial Configuration

A Circle Of Trust that will include OpenWIS 4 must be created. That COT will initially only include the OpenAM IdP. Also, a user whose credentials will be used in order to login to OpenWIS 4 must be created. Because spring-security-saml requires email as a user attribute value, please make sure that you do enter a value for email after the user is created.

Step 2: OpenWIS 4: Spring Configuration

The following line should be un-commented in the file: /openwis-war/src/main/webapp/WEB-INF/config-security/config-security.xml. This will enable the openwis-security-saml application module.

<import resource="config-security-openam.xml"/>

The file /openwis-war/src/main/webapp/WEB-INF/config-security/config-security-openam.xml should be edited and certain sections configured.

The keystore may be modified (if necessary) here:

<!-- Central storage of cryptographic keys -->
<bean id="keyManager" class="org.springframework.security.saml.key.JKSKeyManager">
    <constructor-arg value="classpath:/saml-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>

The URL of the IdP metadata xml generator for the Circle Of Trust that will contain OpenWIS 4 should be entered here:

<bean class="org.opensaml.saml2.metadata.provider.HTTPMetadataProvider">
    <!-- URL containing the metadata -->
    <constructor-arg>
        <value type="java.lang.String">http://openwis3b.eurodyn.com:8080/openam/saml2/jsp/exportmetadata.jsp?entityid=tg-test</value>
    </constructor-arg>
    <!-- Timeout for metadata loading in ms -->
    <constructor-arg>
        <value type="int">15000</value>
    </constructor-arg>
    <property name="parserPool" ref="parserPool" />
</bean>

Due to potential mis-match of the system time on the IdP and SP, this section defines the allowed offset. It may be configured to any suitable value:

<!-- SAML 2.0 WebSSO Assertion Consumer -->
<bean id="webSSOprofileConsumer" class="org.springframework.security.saml.websso.WebSSOProfileConsumerImpl">
    <property name="responseSkew" value="36000"/> <!-- 10 hours -->
</bean>

Same as above, different SAML component:

<!-- SAML 2.0 Logout Profile -->
<bean id="logoutprofile" class="org.springframework.security.saml.websso.SingleLogoutProfileImpl">
    <property name="responseSkew" value="36000"/> <!-- 10 hours -->
</bean>

At this point OpenWIS 4 is fully configured and should be deployed.

Step 3: OpenAM: Final Touch

Now that OpenWIS 4 is deployed successfully, the SP metadata for it may be retrieved and imported it into OpenAM. This can be done by accessing the following OpenWIS 4 URL (modify the hostname and port with your own values):

http://localhost:10080/geonetwork/saml/metadata

Save the xml file and then import it into OpenAM in order to add OpenWIS 4 as a Service Provider. Once the SP is added, the COT created earlier needs to be updated in order to include it.

Step 4: Confirming It Works

The spring-security configuration currently requires authentication for every URL, except for a couple that are required for SSO to work. This means that by opening http://localhost:10080/geonetwork/ the user will be redirected to OpenAM for login, where he should enter the credentials of the user created in step 1. If the credentials are correct, the user will then be logged-in the application as if he was the administrator (explained later) and has full access.

Authentication Flow

The following diagram shows the flow of a request to the application coming from a non-authenticated user:

  • The request is received by OpenWIS.
  • Spring-security decides that a protected resource was requested, so the user must be authenticated.
  • In its current implementation spring-security uses a mechanism in which multiple authentication providers vote for every access request. Afterwards, all the votes are consolidated and a decision is taken concerning access to the resource. The "default" authentication provider will always vote 0 (neutral) and the weight of the final decision will be based on the response from OpenAM.
  • A series of spring-security filters handle the request and redirect to OpenAM for authentication.
  • The user enters his username and password. When he gets them right, he is redirected back to OpenWIS 4, which seeing that he is authenticated will also fetch the user's metadata from OpenAM.
  • Since the sum of votes is positive, the user is allowed access to the resource.

Important Considerations

As mentioned in the introduction this implementation is not production-ready, but only serves as a PoC, because of the combination of the following:

Problem 1. CGN User Management And SSO

Core-Geonetwork manages its users locally and doesn't provide an interface that would allow using a remote User API instead. This means that all the users and their permissions must be stored into OpenWIS 4. As a result, the "recommended" way of doing SSO is to only use the IdP for authentication, and not for authorization. In this fashion, after the user is authenticated, OpenWIS 4 retrieves the username from the IdP and then locally loads that user's permissions.

Problem 2. OpenAM SAML2 And User Attributes

On the OpenAM side, the user attributes transmitted to the SP do not (by default) include the username, as it is considered sensitive information. This means that OpenWIS 4 doesn't have the required information in order to fetch the correct user from its local database.

Current Work-around

The quick-and-dirty solution to the above - since this was only an attempt to verify if SSO with OpenAM was feasible - was to load the "admin" user details for any user that logged-in using OpenAM. This means that as long as the user manages to log into the application, he is an administrator.

Suggested Solutions

In order to make the system production-ready, any of the following solutions will suffice:

  • As mentioned above, the user's email is mandatory for spring-security-saml. This means that if it also becomes mandatory for both OpenAM and OpenWIS 4 users, and assuming it is unique, we will be able to write code that loads a user's details by email instead of username.
  • Adding a custom username field into OpenDJ and OpenAM will allow to store usernames. That way we can fetch them into OpenWIS and use the existing code to load a user's details.

Clone this wiki locally