[cas-dev] Extended Attributes Architecture for 3.1

[Scott Battaglia]

The AuthenticationHandler, AuthenticationManager and
CredentialsToPrincipalResolver are our most public APIs and thus cannot be
changed at this point.  Nor would I probably change them.  Authenticating
credentials and figuring out who you are are two logically separate tasks
and are not necessarily associated with one another.  Your authentication
store is not necessarily the same store as your principal store (in fact
there are often many authentication back ends and one person directory,
etc.).

If we are concerned with resource conservation there are ways of doing it
such as connection pooling, prepared statement caching/pooling, database
optimizations, caching results on the server side, etc. all of which should
be done regardless of whether the act of authenticating and resolving occurs
in one class or two separate classes.

-Scott

On 2/5/07, Stephen A. Cochran <stephen.a.cochran at dartmouth.edu> wrote:
>
> But not really, because even in LDAP, you can do a authenticated
> search, ie BIND to o the query. So you can verify the user/pass at
> the same time as ask for the information. Our local directory service
> (which supports LDAP and a proprietary protocol) also does this; a
> VALIDATE command can also return a query.
>
> So I think it makes sense to architect the authentication manager
> flow to accommodate handlers that could return principals directly
> instead of needing a C2PResolver. If we're going to design a way to
> map one hander to a C2PResolver, we could add the ability to not map
> one at all. This would mean the handler is responsible for returning
> the principal.
>
> Steve
>
> On Feb 5, 2007, at 2:32 PM, Velpi wrote:
>
> > For SQL this makes sense: why hit the same SQL twice (probably even
> > the
> > same table, or most likely the same DB)?
> > For LDAP however there is always a phase where a bind is done as if it
> > were the user itself that's connecting to the directory. In this
> > case it
> > would be nice to have both a persistent and a "switching" connection.
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070205/ff6e6341/attachment.html