Shibboleth Developers

[Chad La Joie <>]

On 7/2/10 3:21 AM, Franck Borel wrote:
> Hi Chad,
>
> > - Ditching the JAAS interface in favor of something else.  The way
> > that JAAS works has a number of limitations, mostly because it was
> > never meant to be used with web apps, and having something
> > specifically designed for such a use case might be better all
> > around.
>
> which interface have you in mind? Spring Security?

I've already had quite an extensive look at Spring Security and it's not 
appropriate for use within the IdP.  It simply makes way to many 
assumption about what an authentication transaction looks like and it 
assumes that there is only ever one such transaction tied to any given 
sessions.

If I do move away from JAAS it will likely be to something that is 
IdP-specific.  I haven't seen anything else that can really support what 
we need.

Many home
> organizations in the DFN-AAI-Federation had to program their own
> connectors to authenticate their users or to connect their IdM to the
> IdP. Some are based on JAAS and others are own creation. It will be
> fine, if the connectors will work with the next release of the IdP
> too. Therefor it will necessary that the next IdP could be backward
> compatible. I don't know if this is part of your plan.

As I stated in the initial email starting the IdP v3 discussion, the 
whole point of incrementing the version number is because I know we have 
to break APIs and therefore custom extensions developers should not 
expect their extensions to "just work" in v3.  It's clear that the 
biggest API differences will be in the profile handler and 
authentication engine.  The attribute resolver and filter engine will 
have slightly different APIs (mostly a reshuffling of which context 
objects contain which data).

> Another ,and I think this is the better way, is implementing the
> missing features :-). This are for example (example is taken from a
> real existing case):

There is no way to implement the missing features for JAAS.  JAAS is a 
standardized API that was designed for desktop applications.  I have no 
way of augmenting it.  So, once I get down to really doing the 
programming, if JAAS is more trouble than it's worth then I won't be 
using it.  Simple as that.

> - Passing any parameters to the authentication process. Example IP
> address, username, password, organization name - Possibility to bind
> scripts, which handle the authentication with the possibility to
> return error messages to the user, like "your account has expired"

This is already possible today.  At the instant the authentication 
engine invokes the login handler the login handler has all the 
information known by the IdP up to that point.  The IP address, 
username/password (when that's the AuthN mechanism) is already 
available.  I have no idea what you mean by organization name.  If 
you're referring to the data in metadata that's available to.

However, if the information isn't available today it won't be in v3 
either because the IdP simply will not have it.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered