The beauty of the CAS design is that if you feel this strongly about the PGT authentication and callback being one too many calls, you can replace the default implementation of the HttpBasedCredentialsAuthenticationHandler (or whatever its called, I always forget) with one that merely checks that the protocol is https and returns true.
The CAS API and implementation are relatively efficient (as far as I know). There are, obviously, defaults designed for maximum plugability, that might not result in maximum performance. If you are concerned about performance, you should look at swapping out those components. If you know your authentication stack and its one authentication method then obviously the AuthenticationManager we use by default has overhead because you're not taking advantage of the loop. The APIs provide a decent mechanism for you to squeeze out maximum performance. Correctly separating authentication from other actions is not an inefficiency, its the proper design. If you didn't properly separate authentication, then you're limiting what you can do. At Rutgers, we had actually swapped out the method in which proxy authentication works (i.e. we returned the PGT as part of the response instead of via the callback) purely because we were able to authenticate them another way (in our case, a secret token). As for CredentialsToPrincipalResolvers and AuthenticationHandlers, this has been discussed multiple times. The source from which you validate the credentials is not necessarily the source from which you retrieve their attributes (i.e. you may use a Safeword card or SPNEGO but then look them up in LDAP). While that may not be the case at your organization, its the case at a large number of organizations. Separating them also allows us to build up a huge collection of default implementations that everyone can share. Cheers, Scott On Fri, May 7, 2010 at 5:09 PM, Nathan Kopp <[email protected]> wrote: > Regarding documentation: I agree with Fredrik. The current implementation > is reasonable, but this detail really should be documented. > > Regarding the efficiency aspect: this double-access of the PGT callback URL > follows an underlying principle that I see other places in the current 3.x > CAS codebase. This principle separates the concept of "authentication" from > whatever action will happen when authentication is successful. This design, > while clean, causes inefficiencies when the underlying action will > effectively perform the authentication all over again. > > You can see this principle played out in the AuthenticationHandler > interface, which takes credentials and returns a simple boolean result. CAS > then must perform the next step using a CredentialsToPrincipalResolver, > which takes those same credentials and returns a principal. Sometimes these > two steps are handled very differently from each other, but sometimes the > CredentialsToPrincipalResolver will actually have to re-authenticate or at > least reconnect to some external system in order to build the principal. > The two operations could have been more efficient if performed together. > > The issue here is that often an underlying protocol (such as HTTPS or LDAP) > will blend the act of authenticating with the act of fetching the resource. > These two actions effectively become one action, at least at the > granularity level with which CAS interacts with many protocols. Yet the > interface design within CAS assumes that the authentication and the > underlying action will always be performed by two separate operations. > > On a related note... I've often thought that AuthenticationHandler and > CredentialsToPrincipalResolver could be blended into one interface, so that > the implementation would return a fully resolved Principal if the > authentication is successful, or return null (or better yet, throw an > exception indicating a reason) if the authentication is not successful. > > Of course, with some combinations of authentication and principal, this > blended design might not be adequate... I haven't really analyzed all > possible use cases. But for all of the uses cases that I've ever used or > considered, the blended interface approach would have been sufficient. > > -Nathan Kopp > > > -----Original Message----- > From: Fredrik Norrström [mailto:[email protected]] > Sent: Friday, May 07, 2010 3:51 PM > To: [email protected] > Subject: Re: [cas-dev] Incomplete Proxy CAS Walkthrough > > Ok, but checking the cert is in reality done before any request, > regardless of parameters, and whether there is something responding at > that URL regardless of parameters. I can't really see any additional > value given by the request without parameters in this regard. > > In fact, as far as I can see there is absolutely nothing in section > 2.5.4 of http://www.jasig.org/cas/protocol either indicating that there > is an additional request without parameters to which I have to respond. > It only states that the certificate and host is validated before any PGT > is issued, which could be done in a single request with parameters, > since the TLS negotiation is done before the actual request is made. > > Neither can I find any indication that I'm able to replace it with other > form of authentication without breaking the protocol. > > This does not really matter, but the behavior should most definitely be > documented, especially if it has any deeper meaning as you suggest. > > Best regards, > /Fredrik > > On Fri, 2010-05-07 at 18:54 +0200, Scott Battaglia wrote: > > I explained why it occurs. Its an authentication request. *You* can > > choose to replace it with some other form of authentication if you'd > > like. > > > > > > On Fri, May 7, 2010 at 12:40 PM, Fredrik Norrström <[email protected]> wrote: > > I think the point is that the undocumented request without any > > parameters at all, to which we are required to respond with > > 200 OK for > > the server to actually make the documented request with the > > PGT, is > > pointless and therefore slightly inefficient. > > > > I happen to agree with this, unless there is some reason for > > this > > additional, undocumented, request which escapes me. > > > > Best regards, > > /Fredrik Jönsson Norrström > > > > On Fri, 2010-05-07 at 16:56 +0200, Scott Battaglia wrote: > > > On Fri, May 7, 2010 at 9:46 AM, Nathan Kopp > > <[email protected]> > > > wrote: > > > <snip /> > > > > > > > > > > > > > > > Note also that I think this call is unnecessary and > > therefore > > > slightly inefficient. > > > > > > It authenticates the PGT request. Its another set of > > authentication > > > credentials. You could easily replace it with some other > > method of > > > authentication (i.e. passing a username/password). The > > point is that > > > a request for a proxy granting ticket is the same process as > > > requesting a TGT. The default authentication method happens > > to be > > > checking the cert and that the end point is responding. Its > > easily > > > sawappable with something else. > > > > > > Cheers, > > > Scott > > > > > > > > > > > > > > -- > > 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 > > > > -- > 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 > > -- 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
