Shibboleth Developers

[Bradley Beddoes <>]

Chad,

Not sure if the way we did things in esoe land might be worth a few
moments of your time or not but the code is located here:

http://github.com/esoeproject/esoeproject/tree/master/esoecore/src/com/qut/middleware/esoe/authn/

Essentially we implemented quite a generic interface for building
authenticators that could pretty much do whatever they wanted and were
invoked in a pipeline approach. The reason we didn't use JAAS is we
too believed it wasn't suitable for web type apps. There is some doco
floating around on how this all works but the server is currently
returning a 500, if you've got further interest i'll flick you the
link once I get them to start that up again next week.

Bradley

On Sat, Jul 3, 2010 at 4:04 AM, Chad La Joie 
<>
 wrote:
>
> 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
>