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
