OpenID is an open, decentralized, free framework for user-centric digital identity. Users represent themselves using URIs. For more information see the http://www.openid.net. As of CAS 3.5, CAS supports both the "dumb" and "smart" modes of the OpenID protocol. Dumb mode acts in a similar fashion to the existing CAS protocol. The smart mode differs in that it establishes an association between the client and the openId provider (OP) at the begining. Thanks to that association and the key exchange done during association, information exchanged between the client and the provider are signed and verified using this key. There is no need for the final request (which is equivalent in CAS protocol to the ticket validation).
A demo of the OpenId support in CAS server is available at : https://github.com/leleuj/cas-openid-demo.
Giving your users URIs
Configuring your users to have URIs.
OpenId identifiers are URIs. The default mechanism in CAS support is an uri ending with the actual user login (ie. http://my.cas.server/openid/fesnault where the actual user login is fesnault). This is not recommended and you should think of a more elaborated way of providing URIs to your users.
Add OpenId support module to CAS server
The first thing, with a CAS server webapp, is to add the OpenId support module dependency. This is done by adding this in the cas server webapp pom.xml.
Code Block | ||
---|---|---|
| ||
<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-support-openid</artifactId>
<version>${project.version}</version>
</dependency> |
Warning | ||
---|---|---|
| ||
You must change the server prefix property of the cas server to an https url. Otherwise SSO will not work. Find the cas.properties file and edit the server.prefix url to something like this : https://localhost:443/cas. |
Now let's dive into CAS configuration itself.
Update webflow
...
Warning | ||
---|---|---|
| ||
CAS documentation has moved over to apereo.github.io/cas, starting with CAS version 4.x. The wiki will no longer be maintained. For the most recent version of the documentation, please refer to the aforementioned link. |
Tip |
---|
Since CAS version 4.0, in addition to this server support, a new OpenID client support is available in the CAS server through the cas-server-support-pac4j module. It means that the CAS authentication can be delegated to www.myopenid.com. |
OpenID is an open, decentralized, free framework for user-centric digital identity. Users represent themselves using URIs. For more information see the http://www.openid.net. As of CAS 3.5, CAS supports both the "dumb" and "smart" modes of the OpenID protocol. Dumb mode acts in a similar fashion to the existing CAS protocol. The smart mode differs in that it establishes an association between the client and the openId provider (OP) at the begining. Thanks to that association and the key exchange done during association, information exchanged between the client and the provider are signed and verified using this key. There is no need for the final request (which is equivalent in CAS protocol to the ticket validation).
A demo of the OpenId support in CAS server is available at : https://github.com/leleuj/cas-openid-demo.
Giving your users URIs
Configuring your users to have URIs.
OpenId identifiers are URIs. The default mechanism in CAS support is an uri ending with the actual user login (ie. http://my.cas.server/openid/fesnault where the actual user login is fesnault). This is not recommended and you should think of a more elaborated way of providing URIs to your users.
Add OpenId support module to CAS server
The first thing, with a CAS server webapp, is to add the OpenId support module dependency. This is done by adding this in the cas server webapp pom.xml.
Code Block | ||
---|---|---|
| ||
<dependency> <!-- If the request contains a parameter called openid.mode and is not an association request, switch to openId. Otherwise, continue normal webflow. --> <decision-state id="selectFirstAction"> <if test="externalContext.requestParameterMap['openid.mode'] neq '' && externalContext.requestParameterMap['openid.mode'] neq null <groupId>org.jasig.cas</groupId> <artifactId>cas-server-support-openid</artifactId> <version>${project.version}</version> </dependency> |
Warning | ||
---|---|---|
| ||
You must change the server prefix property of the cas server to an https url. Otherwise SSO will not work. Find the cas.properties file and edit the server.prefix url to something like this : https://localhost:443/cas. |
Now let's dive into CAS configuration itself.
Declare the OpenID endpoint (since CAS 4.0)
Since CAS 4.0, the OpenID endpoint for discovery is no more enabled by default in the CAS server (in fact, it is no more available in the cas-server-support-webapp module : it has been moved to the cas-server-support-openid module).
The OpenID discovery endpoint should be enabled during the configuration process. In the web.xml file, the following mapping must be added :
Code Block | ||||
---|---|---|---|---|
| ||||
<servlet-mapping>
<servlet-name>cas</servlet-name>
<url-pattern>/openid/*</url-pattern>
</servlet-mapping> |
In the cas-servlet.xml file, the following mapping and bean must be added :
Code Block | ||||
---|---|---|---|---|
| ||||
<bean id="handlerMappingC" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/logout">logoutController</prop>
...
<prop key="/openid/*">openIdProviderController</prop>
...
<bean
id="openIdProviderController"
class="org.jasig.cas.support.openid.web.OpenIdProviderController"
p:loginUrl="${server.prefix}/login"/> |
Add the OpenID entry in the unique id generator map (since CAS 4.0)
Since CAS 4.0, the OpenID entry in the unique id generator map is no more defined by default in the CAS server.
The OpenID entry should be added to the uniqueIdGenerators.xml file :
Code Block | ||||
---|---|---|---|---|
| ||||
<util:map id="uniqueIdGeneratorsMap">
...
<entry
key="org.jasig.cas.support.openid.authentication.principal.OpenIdService"
value-ref="serviceTicketUniqueIdGenerator" />
</util:map> |
Update webflow
CAS uses a spring webflow to describe the the authentication process. We need to change it a little bit to allow CAS to switch to OpenId authentication if it recognizes one. This is done in the login-webflow.xml fie. After the on-start element just add these two blocks :
Code Block | ||
---|---|---|
| ||
<!-- If the request contains a parameter called openid.mode and is not an association request, switch to openId. Otherwise, continue normal webflow. -->
<decision-state id="selectFirstAction">
<if
test="externalContext.requestParameterMap['openid.mode'] neq ''
&& externalContext.requestParameterMap['openid.mode'] neq null
&& externalContext.requestParameterMap['openid.mode'] neq 'associate'"
then="openIdSingleSignOnAction" else="ticketGrantingTicketExistsCheck" />
</decision-state>
<!-- The OpenID authentication action. If authentication is successful, send the ticket granting ticker. Otherwise, redirect to the login form. -->
<action-state id="openIdSingleSignOnAction">
<evaluate expression="openIdSingleSignOnAction" />
<transition on="success" to="sendTicketGrantingTicket" />
<transition on="error" to="viewLoginForm" />
<transition on="warn" to="warn" />
</action-state> |
...
Then, in the authentication handler property, add this bean definitio definition :
Code Block | ||
---|---|---|
| ||
<!-- The open id authentication handler --> <bean class="org.jasig.cas.support.openid.authentication.handler.support.OpenIdCredentialsAuthenticationHandler" p:ticketRegistry-ref="ticketRegistry" /> |
...
We now have to make CAS handle nicely the OpenId request he will be presented with. First, we'll add a handler for the /login url, when called to validate a ticket (CAS is implementing the dumb OpenId mode, which means it does not create an association at the beginning of the authentication process. It must then check the received authentication success notification, which is done by one extra HTTP request at the end of the process). Anywhere in the cas-servlet.xml file, add this bean definition :
...
In the handlerMappingOpenId, we referenced a bean called delegatingController. this bean is a special controller, using the Delegate pattern, which delegates the processing of a request to the first controller of its delegates which says it can handle it. So now we'll provide two delegate controllers. The first one is handling the Smart OpenId association, and the second process the authentication and ticket validation. Add this two beans in the file.The Smart OpenId request to the first controller of its delegates which says it can handle it. So now we'll provide two delegate controllers. The first one is handling the Smart OpenId association, and the second process the authentication and ticket validation. Add this two beans in the file.
The Smart OpenId controller :
Code Block | ||
---|---|---|
| ||
<bean id="smartOpenIdAssociationController" class="org.jasig.cas.support.openid.web.mvc.SmartOpenIdController"
p:serverManager-ref="serverManager"
p:successView="casOpenIdAssociationSuccessView" p:failureView="casOpenIdAssociationFailureView" /> |
The OpenId validation controller :
Code Block | ||
---|---|---|
| ||
<bean id="openIdValidateController" class="org.jasig.cas.web.ServiceValidateController" <bean id="smartOpenIdAssociationController" class p:validationSpecificationClass="org.jasig.cas.support.openid.web.mvc.SmartOpenIdController"validation.Cas20WithoutProxyingValidationSpecification" p:centralAuthenticationService-ref="centralAuthenticationService" p:proxyHandler-ref="proxy20Handler" p:serverManagerargumentExtractor-ref="serverManageropenIdArgumentExtractor" p:successView="casOpenIdAssociationSuccessViewcasOpenIdServiceSuccessView" p:failureView="casOpenIdAssociationFailureViewcasOpenIdServiceFailureView" /> |
The OpenId validation controller :We are done with the delegates. Now we must create the Delegating controller itself, and give it a list of delegates referencing the two delegates we just defined. So add this definition :
Code Block | ||
---|---|---|
| ||
<bean <bean id="openIdValidateControllerdelegatingController" class="org.jasig.cas.web.ServiceValidateController" p:validationSpecificationClass="org.jasig.cas.validation.Cas20WithoutProxyingValidationSpecification" p:centralAuthenticationService-ref="centralAuthenticationService" p:proxyHandlerDelegatingController" p:delegates-ref="proxy20HandlerdelegateControllers" p:argumentExtractor-ref="openIdArgumentExtractor" p:successView="casOpenIdServiceSuccessView" p:failureView="casOpenIdServiceFailureView" /> |
We are done with the delegates. Now we must create the Delegating controller itself, and give it a list of delegates referencing the two delegates we just defined. So add this definition :
...
/>
<util:list id="delegateControllers">
<ref bean="smartOpenIdAssociationController"/>
<ref bean="openIdValidateController"/>
</util:list> |
Also, add the indicated lines to the <beans> definition at the top of the file, if they're not already there:
Code Block | ||
---|---|---|
| ||
<beans <bean idxmlns="delegatingController" class="org.jasig.cas.web.DelegatingController" p:delegates-ref="delegateControllers"/> <util:list id="delegateControllers"> <ref bean="smartOpenIdAssociationController"/> <ref bean="openIdValidateController"/> </util:list>http://www.springframework.org/schema/beans" ... xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation="... http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.1.xsd ..."> |
Next, we'll give CAS a handler for the OpenIdSingleSignOnAction we added in the spring webflow definition file. So add this bean definition anywhere :
...