Creating Custom CAS Login

[jpwinans]

Hey All,

Okay, I've got two applications that I'd like to tie together using CAS single sign on. One application is a trouble ticket system that allows employees to post tickets from a web page. The other application is a sign-in / sign-out time sheet app that employees log in and out of to keep track of breaks and lunches. The CAS and Acegi would also provide standard role-based security for supervisors and the IT team.
What I would like to do is integrate CAS into the time sheet application in the following customized way. I'd like them to have to log in with name, password, AND their phone extension. See, it is a call center and the employees move around, but a computer and IP address remains with the phone. Upon sign-in, I'd like to have the application find the computer associated with the extension, and then associate that computer with the user.
This way, as they are logging in and out, the system is always up to date with what computer they are using. Then when they log in to send a trouble ticket, the system will automatically tie the appropriate computer to that ticket.
How would I go about creating this custom login that takes the extension? Should I modify the CAS servlet? Should I just create a separate login page after the CAS login?
Also, I would like for CAS to know when they are logged in or out throughout the entire work day, even if they close their browser. How might I preserve this?
Any help would be great. This is my first real Java enterprise project, and I'm having to tackle Java, Spring, CAS, and Acegi all at once. But I'm sure greatful for how Spring is allowing me to manage the complexity. I'd really appreciate help on the starting point here.

Thanks,
James

[jpwinans]

Okay, for anyone interested, here is what I've done so far...

I've decided to modify edu.yale.its.tp.cas.servlet.Login to add a phone extension to the authentication call in doGet()...

...
} else if (handler instanceof PasswordHandler
        && request.getParameter("username") != null
        && request.getParameter("password") != null
        && request.getParameter("extension") != null
	    && request.getParameter("lt") != null) {
      // do we have a valid login ticket?
      if (ltCache.getTicket(request.getParameter("lt")) != null) {
	// do we have a valid username and password, and extension?
        if (((PasswordHandler) handler).authenticate(request,
          request.getParameter("username"), request.getParameter("password"),
          request.getParameter("extension"))) {
          // success: send a new TGC if we don't have a valid TGT from above
...

Thus, I also had to modify the Acegi CasPasswordHandlerProxy and CasPasswordHandler to check to make sure an extension was given.

Where I am now, is wondering if I should pass this phone extension to the TimeSheet application, or have my custom CAS Login class do the association itself. ???

[Ben Alex]

Just as a rule of thumb, I would not be modifying the CAS core infrastructure unless absolutely unavoidable. It's also representing a mixing of concerns, as authentication != location services.

Is there a way of resolving the phone extension based on the provided IP address? That way you could use the fact CasProcessingFilter sets the remote IP address in the UsernamePasswordAuthenticationToken.setDetails(). If so, you would then be able to have your timesheet application just go lookup the phone extension based on the ((SecureContext)ContextHolder.getContext()).getAut hentication().getDetails().

[jpwinans]

Hey,

Well, I hadn't really considered that. I've actually got my customization of CAS working, however I'm getting an error on Logout. So I will certainly consider this suggestion. Where can I find what else is included in that token?

Thanks a lot,
James

[Ben Alex]

The only core Acegi Security class which directly interacts with a CAS class is the CasProxyTicketValidator. You might find something useful in there, but I'd be looking at separating the location service from the authentication service if possible instead.

[Scott Battaglia]

Just to build on what Ben was saying. If extension information is not part of the credentials used to authenticate a user or later used to determine the authorization into the system, they should not be included in CAS.

CAS is only concerned with determining the authenticity of the user and passing the attributes of the user (in CAS 2 this is only the Netid, CAS 3 will include the option of attributes) to the requesting application so that it can make a determination of authorization.

In addition as Ben said you should look into decoupling the location service aspect from the authentication service if possible. If you decide to replace the authentication service with say NT Challenge/Response you should not have to change the way the location service works.