Recently I started on Shibboleth, and CAS integration. While the documentation for both Shibboleth, and CAS are pretty good, still there are areas where improvements can be made describing the problem determination. As both Shibboleth, and CAS are open source products, apart from expensive commercial support, web is the major source for solving the integration issues. This blog is provides some of the issues I encountered, solved which could be useful for the beginners. First to start with the architecture I used:
CAS installation was pretty straight forward, and thanks to SimpleTestUsernamePasswordAuthenticationHandler provided by CAS developers which makes testing CAS installation simple. For SimpleTestUsernamePasswordAuthenticationHandler the userid, and password are the same, and authentication by CAS can be tested quickly.
Now comes the beast, Shibboleth. After installing, and configuring Identity Provider, and Service Provider as detailed in Shibboleth's wiki, still it is very difficult to test the federation. Had to spend five days to make Shibboleth, and CAS integration work. Worthy to note is the fact that as documented by Shibboleth for IdP installation IdP is deployed as a war file. As such any changes to be made to web.xml of IdP during CAS integration requires unjaring idp.jar, make changes to web.xml, and rejar idp.jar for the changes to be effective. The issues encountered without this procedure are described later.
Issues encountered during Shibbolith IdP, and SP testing:
After completing Idp, and SP configuration, the exciting testing of federation results in a disappointment, and panic with the following message:
opensaml::FatalProfileException
The system encountered an error at Sat Oct 26 06:28:11 2013
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
opensaml::FatalProfileException at (https://sp.host.local:9443/Shibboleth.sso/SAML2/POST)
SAML response contained an error.
Error from identity provider:
Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
Time to scour the IdP, and SP, and scouring the log files do not provide any useful messages. Having spent few hours, changed LoginHandler to UsernamePassword from RemoteUser. Handler.xml in IdP configuration directory is the place to change this. Microsoft Active Directory is used as user store. LDAP server is configured in the file /opt/shibboleth-idp/conf/login.config. Shibbolith's default login page is displayed. Trying to login with a valid userid, and password as configured in LDAP, results in another disappointment, the login page is displayed. idp-prcoess.log shows the following exception message:
06:39:55.557 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:197] - User authentication for tester failed
java.lang.SecurityException: Configuration Error:
No such file or directory
at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:110) ~[na:1.7.0_40]
Atleast the message is clear that the file is not found. This is attributed to the JDK1.7 bug for a file URL. The stanza for the LoginHandler UsernamePassword reads as:
<ph:LoginHandler xsi:type="ph:UsernamePassword"
jaasConfigurationLocation="file://C:\opt\shibboleth-idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>
Restarted IdP's tomcat after correcting jassConfigurationLocation from file://C:\opt\shibboleth-idp/conf/login.config to file:///C:\opt\shibboleth-idp/conf/login.config. Another login failure message when trying to login with valid userid, and password. The error message as shown in idp-process.log file is:
DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164] - Error occured attempting authentication
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-03100213, problem 2001 (NO_OBJECT), data 0, best match of:
''
]
Based on someone's blog corrected the LDAP configuration entries to:
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://W2K12.shibbolith.local:389"
base="CN=Users,DC=shibbolith,DC=local"
ssl="false"
userField="sAMAccountName"
userFilter="name={0}"
subtreeSearch="true"
serviceUser="CN=Administrator,CN=Users,DC=shibbolith,DC=local"
serviceCredential="secret";
The semicolon at the end is important. Restarted tomcat server. Finally was rewarded with a successful federation.
Shibbolith,and CAS integration requires using RemoteUser as the LoginHandler. Change the LoginHandler to RemoteUser as below:
<ph:LoginHandler xsi:type="ph:RemoteUser">
<ph:AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</ph:AuthenticationMethod>
<ph:AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
</ph:LoginHandler>
Note the namespace ph. The namespace is not mentioned in the documentation.
Deploy idp.war after making necessary changes to web.xml as described in the documentation, after unjaring, and rejaring.
idp wouldnot start with the message:
SEVERE: The web application [/idp] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak.
Tomcat's localhost.log file contains the error details:
SEVERE: Exception starting filter CAS Validation Filter
java.lang.ClassNotFoundException: org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
This indicates that CAS client library is missing in idp.war. Redeploy idp.war after including cas client library in idp.war/lib directory. idp starts without issues, and login page from CAS is deployed while trying to access a secured resource. Entering a valid userid/password would result in successful federation.
The joy open source software.
.
CAS installation was pretty straight forward, and thanks to SimpleTestUsernamePasswordAuthenticationHandler provided by CAS developers which makes testing CAS installation simple. For SimpleTestUsernamePasswordAuthenticationHandler the userid, and password are the same, and authentication by CAS can be tested quickly.
Now comes the beast, Shibboleth. After installing, and configuring Identity Provider, and Service Provider as detailed in Shibboleth's wiki, still it is very difficult to test the federation. Had to spend five days to make Shibboleth, and CAS integration work. Worthy to note is the fact that as documented by Shibboleth for IdP installation IdP is deployed as a war file. As such any changes to be made to web.xml of IdP during CAS integration requires unjaring idp.jar, make changes to web.xml, and rejar idp.jar for the changes to be effective. The issues encountered without this procedure are described later.
Issues encountered during Shibbolith IdP, and SP testing:
After completing Idp, and SP configuration, the exciting testing of federation results in a disappointment, and panic with the following message:
opensaml::FatalProfileException
The system encountered an error at Sat Oct 26 06:28:11 2013
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
opensaml::FatalProfileException at (https://sp.host.local:9443/Shibboleth.sso/SAML2/POST)
SAML response contained an error.
Error from identity provider:
Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
Time to scour the IdP, and SP, and scouring the log files do not provide any useful messages. Having spent few hours, changed LoginHandler to UsernamePassword from RemoteUser. Handler.xml in IdP configuration directory is the place to change this. Microsoft Active Directory is used as user store. LDAP server is configured in the file /opt/shibboleth-idp/conf/login.config. Shibbolith's default login page is displayed. Trying to login with a valid userid, and password as configured in LDAP, results in another disappointment, the login page is displayed. idp-prcoess.log shows the following exception message:
06:39:55.557 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:197] - User authentication for tester failed
java.lang.SecurityException: Configuration Error:
No such file or directory
at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:110) ~[na:1.7.0_40]
Atleast the message is clear that the file is not found. This is attributed to the JDK1.7 bug for a file URL. The stanza for the LoginHandler UsernamePassword reads as:
<ph:LoginHandler xsi:type="ph:UsernamePassword"
jaasConfigurationLocation="file://C:\opt\shibboleth-idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>
Restarted IdP's tomcat after correcting jassConfigurationLocation from file://C:\opt\shibboleth-idp/conf/login.config to file:///C:\opt\shibboleth-idp/conf/login.config. Another login failure message when trying to login with valid userid, and password. The error message as shown in idp-process.log file is:
DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164] - Error occured attempting authentication
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-03100213, problem 2001 (NO_OBJECT), data 0, best match of:
''
]
Based on someone's blog corrected the LDAP configuration entries to:
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://W2K12.shibbolith.local:389"
base="CN=Users,DC=shibbolith,DC=local"
ssl="false"
userField="sAMAccountName"
userFilter="name={0}"
subtreeSearch="true"
serviceUser="CN=Administrator,CN=Users,DC=shibbolith,DC=local"
serviceCredential="secret";
The semicolon at the end is important. Restarted tomcat server. Finally was rewarded with a successful federation.
Shibbolith,and CAS integration requires using RemoteUser as the LoginHandler. Change the LoginHandler to RemoteUser as below:
<ph:LoginHandler xsi:type="ph:RemoteUser">
<ph:AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</ph:AuthenticationMethod>
<ph:AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
</ph:LoginHandler>
Note the namespace ph. The namespace is not mentioned in the documentation.
Deploy idp.war after making necessary changes to web.xml as described in the documentation, after unjaring, and rejaring.
idp wouldnot start with the message:
SEVERE: The web application [/idp] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak.
Tomcat's localhost.log file contains the error details:
SEVERE: Exception starting filter CAS Validation Filter
java.lang.ClassNotFoundException: org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
This indicates that CAS client library is missing in idp.war. Redeploy idp.war after including cas client library in idp.war/lib directory. idp starts without issues, and login page from CAS is deployed while trying to access a secured resource. Entering a valid userid/password would result in successful federation.
The joy open source software.
.
