CAS is probably the most used open access manager, let's spice it with SAML 2.0.

As you probably already know Jasig CAS is one of the most famous and used access manager open source software. This means that it doesn't need a presentation, but those who know it well also knows that Jasig CAS doesn't provide any SAML 2.0 feature out-of-the-box. This means that having CAS acting as SAML Identity Provider or Service Provider is always a complicated job.

Few months ago, however, one of our customers needed to migrate its IAM solution from proprietary to a brand new open source based solution. We naturally chose Apache Syncope to manage identity profiles and Jasig CAS to manage SSO and authorization. Such customer had stronger SAML requirements, either as Service Provider and Identity Provider. After some days of analysis we decided to extend CAS with Shibbolet; in the following I am going to explain how we did.

SAMLServiceProvider and the idea

To achieve our requirements we started from a SAMLServiceProvider module as an authentication module served by CAS. The idea was to start the SAML protocol from a new CAS servlet and, at the end of the SAML exchange, if the SAML session was successfully initialized, to create a CAS session so that CAS could be empowered to protect services and achieve SSO.

Development

As you can see in the following image

we added the SAML classes in the CAS project. After this step we configured the web.xml adding the necessary servlets

  <servlet>
    <servlet-name>Authentication</servlet-name>
    <servlet-class>net.tirasa.saml.Authentication</servlet-class>
  </servlet>
  <servlet>
    <servlet-name>Metadata</servlet-name>
    <servlet-class>net.tirasa.saml.Metadata</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>Authentication</servlet-name>
    <url-pattern>/SPInitiator</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>Metadata</servlet-name>
    <url-pattern>/metadata</url-pattern>
  </servlet-mapping>

The only two necessary servlets are:

  • Metadata: to exchange the metadata;
  • Authentication: to start the SAML protocol.

The most important difference between the original Service Provider module and the new one is that the consumer is located on the login servlet of the CAS server:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://www.host.it/cas/login" index="0"/>

What does it mean?

It means that, after authentication process concludes on the IdP, the SAML flow ends where the CAS flow starts. Is it brilliant, isn't it?

To get this behavior we have an action state with a custom action called SwitchAction able to figure out if someone is calling the SAML protocol to call the right class, in this case the Consumer class.

Another step to underline is that the Consumer class (as you see from the github project) was split in different parts in order to get a CAS authentication module like the SPNEGO one (the latter doesn't ask for password, similarly to our SAML module).

I am stopping here because how to build a CAS authentication module (or the specific SAML module) could be an argument for a new post, but, if you are interested to know more details about this Jasig CAS as SAML Service Provider don't hesitate to call or e-mail.

1 VOTIYes, Excellent!Yes, Excellent!
Ti è stato utile questo articolo?
From Tirasa's Blog
The place where we share what we do, learn and discover day by day.
Go to blog >