SSO and Federated Identify Management

SSO, or Single Signon, is a way for organizations to centralize their identity management and authentication needs in a consolidated, single solution across multiple applications in the enterprise. There are quite a few solutions available to enterprise to implement SSO with. Jetspeed classifies SSO in two categories:

  • Jetspeed SSO
  • External Identity Management Solutions

The first, Jetspeed SSO, is a rather simpler solution for enterprise applications who do not need the complexity of a robust identity management SSO solution. In this case, Jetspeed provides a credential store for user credentials. Jetspeed can store encrypted credentials for users or groups of users to external sites. The second solution requires a third party open source project or product. In this case, Jetspeed integrates with an external SSO solution. These external solutions can often a single-signon solution for an organization, or even a federation of organizations.

Jetspeed SSO

Jetspeed SSO uses Jetspeed and Java security to implement a set of services and portlets for storing credentials. A management administrative portlet allows the editing of SSO sites and remote credentials. Jetspeed SSO comes with a secure IFrame and Web Content set of portlets. These portlets allow you to secure access to external sites. Authentication suport includes:

  • Basic authentication is the default and can be supported effectively without even setting the sso.type preference. Simply provide credentials for the domain, and basic authentication defaults. The credentials will not be sent preemptively, but if a 401 request is returned for Basic authentication, it will be handled properly. This is equivalent to setting the preference sso.type=basic (or sso.type=html (old - now deprecated in favor of calling it basic). if you set sso.type=basic.preemptive, it will send the credentials preemptively.
  • URL authentication (query args) is supported as sso.type=url or sso.type=url.base64. By definition, this type of authentication is preemptive, so no distinction is made there.
  • Form-authentication is supported with sso.type=form (which is equivalent to sso.type=form.post - you can also specify sso.type=form.get, if GET protocol is used on the login form). This form also requires a bunch of other data ( e.g. the action URL, other args, names of the fields for credentials, etc.). All of this is in an example that is in the demo portlet.xml. Form-based authentication is also considred "preemptive", in that it authenticates before any other content is read. However, it only does it once. If it succeeds, all should be well. If it fails, the user will have to login by hand (since the initial content URL will cause a redirect to the login page).
  • Here are some examples of preferences that can be set for the SSO IFrame and SSO Content portlets:
                <preference>
                    <name>sso.type</name>
                    <value>basic | url | form</value>
                </preference>
                <preference>
                    <name>sso.url.Principal</name>
                    <value>sso-principal</value>
                </preference>
                <preference>
                    <name>sso.url.Credential</name>
                    <value>sso-credential</value>
                </preference>            
                <preference>
                    <name>SRC</name>
                    <value>http://www.nytimes.com</value>
                </preference>
                <preference>
                    <name>sso.type</name>
                    <value>form</value>
                </preference>
                <preference>
                    <name>sso.form.Action</name>
                    <value>http://www.nytimes.com/auth/login</value>
                </preference>
                <preference>
                    <name>sso.form.Principal</name>
                    <value>USERID</value>
                </preference>
                <preference>
                    <name>sso.form.Credential</name>
                    <value>PASSWORD</value>
                </preference>
                <preference>
                    <name>sso.form.Args</name>
                    <value>Submit2=Log In;OP=;OQ=;is_continue=false</value>
                </preference>
    

Integrating with External SSO

To enable an identity management service, such as Site Minder, or Shibbboleth (see below), there are some general guidelines for integrating your SSO solution with Jetspeed. remove the Login Portlet from the custom build and delegate authentication to the authentication provider. Upon successful authentication, redirect to the portal.

  1. Remove the Login Portlet from your custom home page. You will no longer need it. The third party SSO will handle all authentication. You will need to configure the third party SSO to redirect to the Jetspeed portal upon successful authentication. All authentication activities are removed from Jetspeed.
  2. Modify the Jetspeed web.xml to include any required settings for your SSO solution. You might need to enable this filter and mapping:
    			
      <filter>
        <filter-name>PortalFilter</filter-name>
        <filter-class>org.apache.jetspeed.login.filter.PortalFilter</filter-class>   
      </filter>
      <filter-mapping>
        <filter-name>PortalFilter</filter-name>
        <url-pattern>/*</url-pattern>    
      </filter-mapping>  
    
  3. Additional edits to the Jetspeed web.xml recommended:
    • remove security-config for the login portlet
      							
        <login-config>
          <auth-method>FORM</auth-method>
          <realm-name>Jetspeed</realm-name>
          <form-login-config>
            <form-login-page>/login/login</form-login-page>
            <form-error-page>/login/error</form-error-page>
          </form-login-config>
        </login-config>
      
    • Remove the servlets: LoginProxyServlet, LoginServlet, LoginErrorServlet, LoginRedirectorServlet and LogoutServlet
    • Remove the servlet-mappings for the above servlets

Shibboleth

Jetspeed comes with a Shibboleth filter for performing Single Sign-on (SSO) with Shibboleth and the Jetspeed Portal. Shibboleth's Service Provider provides HTTP request headers. The filter reads and interprets the Shibboleth headers as single sign-on tokens. Shibboleth can also be configured to provide various user attributes that can be passed onto the portal. Refer to your Shibboleth documentation for more details. The Jetspeed Shiboleth filter is configured in the Jetspeed web.xml:

<filter>
    <filter-name>ShibbolethPortalFilter</filter-name>
    <filter-class>org.apache.jetspeed.security.impl.shibboleth.ShibbolethPortalFilter
    </filter-class>   
</filter>

If there are no Shibboleth headers present, Jetspeed will not authenticate the user. If there are Shibboleth tokens on the HTTP request, Jetspeed will use them and automatically authenticate users, bypassing Jetspeed's internal authentication and login mechanisms.

To configure Jetspeed to use Shibboleth headers, there is a Spring configuration file found under WEB-INF/assembly/alternate/shibboleth.xml:

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<bean id="org.apache.jetspeed.security.shibboleth.ShibbolethConfiguration"
 class="org.apache.jetspeed.security.impl.shibboleth.ShibbolethConfiguration">
    <!-- map of common jetspeed-security principals to shibboleth headers -->
    <constructor-arg index='0'>
      <map>
        <entry key='username'>
          <value>shib-person-commonname</value>
        </entry>
	  </map>
	</constructor-arg>
	<!-- Always authenticate against Jetspeed (should be false if your jetspeed db != authentication users) -->
    <constructor-arg index='1'>
       <value type="boolean">true</value>    
	</constructor-arg>
    <constructor-arg index='2'>
	 	<ref bean="PortalConfiguration" />
	</constructor-arg>
  </bean>
</beans>

The first constructor argument is a map of common jetspeed security names. Currently we only support mapping the username from a Shibboleth principal. It is configured to map to the Shibboleth header/attribute named sub-person-commonname.

The second constructor turns on or off Jetspeed authentication. Turn this off if you simply want to trust Shibboleth or if you don't have passwords available in constructor-arg one.