Thanks, Marvin. We didn't want to put actual code into the document for two reasons:
1. We wanted the document to be easily readable by technical people who weren't necessarily developers 2. We wanted to steer clear of any IP controversy that might arise from discussing what could be deemed to be our employer's confidential information (modified source code). However, I think there will be value in letting this forum know about extensions we had to make to CAS to get it to meet our requirements, so that these features can be incorporated into the mainstream source code, if possible. As the developer on the project, Umesh has done a good job of documenting all the places where he had to make changes to CAS code (and bundle the modified classes as in-house code), because either the CAS classes were declared 'final' preventing them from being extended, or something similar. --- begin summary --- Client side (for the GuideWire ClaimCenter application): 1. The getPropertyFromInitParams(...) method of org.jasig.cas.client.util.AbstractConfigurationFilter is final. The code that comes with CAS is configured to read the config values from either web.xml or JNDI. We wanted to read the values from System property. As the method is final, we removed the AbstractConfigurationFilter.class from the CAS jar file and created org.jasig.cas.client.util.AbstractConfigurationFilter in our project. Our AbstractConfigurationFilter is almost same as the one that came with CAS, except that it can also read the config values from the System properties. 2. We had a requirement to display customised login pages depending on the B2B business partner organisation whose portal the user was being redirected from. The portals were instructed to pass in a "legal entity" parameter to the protected application that indicated which organisation it was. To send the legalEntity parameter as a part of the redirect url from the app to the sso we created our org.jasig.cas.client.authentication.QbeAuthenticationFilter instead of using org.jasig.cas.client.authentication.AuthenticationFilter. The method we had to modify was doFilter(). This method was final in the CAS code, so instead of extending the CAS AuthenticationFilter we created a new class QbeAuthenticationFilter (by copy -pasting the CAS class). 3. We use QbeHttpServletRequestWrapperFilter instead of org.jasig.cas.client.util.HttpServletRequestWrapperFilter because we want the request.getRemoteUser() to return the associated system user instead of the IAM login username. (Associated systems are backend systems on which the user is provisioned with a different name. The protected application has to make service calls to the associated system with the user's login ID on that system as one of the parameters. CAS retrieves this user ID as one of the user's attributes and passes it back to the application when it receives a Service Token validation request.) 4. We use QbeCas20ProxyReceivingTicketValidationFilter that extends Cas20ProxyReceivingTicketValidationFilter. QbeCas20ProxyReceivingTicketValidationFilter does the access control to ClaimCenter by checking if the user has been assigned the proper role. This is achieved by using a new web.xml init param called qbeRoles to define the roles that the user must be assigned for the user to access ClaimCenter. Server side: 1. QbeCentralAuthenticationService that delegates all the tasks to CentralAuthenticationServiceImpl except the validateServiceTicket() method. We had to do this to satisfy the unique requirement of QBE that wanted to send only application specific attributes (such as roles assigned to the particular application) instead of sending all the attributes. 2. QbeLdapAuthenticationHandler to do the Open Ldap authentication. The CAS documentation mentions that we have to have our own authentication handler, because the default SimpleTestUsernamePasswordAuthenticationHandler authenticates UsernamePasswordCredentials where the username equals the password. 3. There are a few login web flow customisation such as CheckIfPasswordChangeRequiredAction and CheckIfSetSecurityQuestionRequiredAction. The login flow is further modified to make the SPNEGO authentication work according to our requirements. Besides the standard modification mentioned at https://wiki.jasig.org/display/CASUM/SPNEGO, the other customisation revolve around making authentication successful even if the browser does not support SPNEGO and when the SPNEGO authentication is unsuccessful (e.g. due to invalid SPNEGO token sent by the browser). When the SPNEGO authentication is unsuccessful we indicate this fact to the client app by setting the LAN ID to 'unauthenticated' (also the employeeId would be ZZZZZZ). --- end summary --- Regards, Ganesh On 5 August 2011 00:10, Marvin Addison <[email protected]> wrote: >> We implemented an Identity and Access Management system in >> 2009, using CAS as the ticketing server for Single Sign-On.... >> We have extended the system in many ways, and CAS continues >> to scale well. > > I'm pleased with your successful CAS deployment. I hope you discuss > the CAS extensions at least briefly in the paper you cited. > >> The developer on this project (Umesh Rajbhandari) and I have written a >> paper based on our experience: http://bit.ly/rmvspE . > > Thanks for sharing this. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
