> When the CAS filter redirects the application to the CAS server we want to > intercept the request and see if there is a Access Manager token (cookie) and > validate it. If the token is valid we want to return to the filter that the > user is valid. Same as if the application had a valid CAS ticket.
What you have described is _not_ an authentication handler. You want one of two different ticket-granting-ticket tokens to be equivalent in a single SSO session. That is going to be a pretty core change to CAS (e.g. CentralAuthenticationServiceImpl) and is not a simple add-on module. An authentication handler, on the other hand, is for establishing a _new_ SSO session from primary credentials. You have made it clear that the Access Manager token is equivalent to the CAS TGT, so it is by no means a primary credential and is not suitable for handling by an authentication mananger. > A little knowledge is dangerous. My architect read the wiki page on X509 > handlers and decided it would be very easy to just write a handler that is > configured the same way (pom.xml, web-flow.xml, cas-serlvet.xml) but instead > of validating an x509 cert it would simply validate the Access Manager token. This is a dead-end strategy; you will not be able to accomplish your goal as stated by creating an authentication handler for Access Manager tokens. > He is convinced this is the way to go, it's easy and I should have it > completed by Friday. My personal feeling is that this a hack and kludge, but > I have little or no say in the matter. It doesn't have to be a kludge, but it is a substantial change that will take time to develop and will merit commensurate testing. A Friday deadline that includes testing and Q/A is wholly unreasonable. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
