Shibboleth Developers

> My read on the OSID concept of authentication is that the only way you could
> do it is by creating what amounts to a generic "REMOTE_USER" OSID whose
> function was to enable SSO-based deployments that assert identity to the
> application to extract the identity from REMOTE_USER and create the
> necessary internals.
>
> To make it work, obviously the web server config has to be laid out such
> that the "login" process runs through that filter in some way and feeds the
> OSID. This isn't too uncommon with CMS integration, since they usually force
> logins through one script and then gateway it into an app session cookie.

there has been some talk about "shib-enabling sakai", and that effort 
would follow the route Scott described above. We probably wouldn't 
make a decision about whether or not to use the Authn OSID until we 
actually got to implementing. The primary difference between a 
"standard" Authn implementation using REMOTE_USER and a Shib 
implementation would be some thinking about how to handle REMOTE_USER 
values that looked like "user@domain". I expect that this approach 
would work just fine for the situation you're describing.

There are lots of other sakai-related use cases that would require 
functionality similar to that described in Scott's recent Delegation 
Profile. (eg student log's into sakai, proceeds to use a tool that 
requires authenticated access to a repository using the student's 
credentials, etc). The current definition of the Authn OSID starts to 
have trouble with use cases of this ilk......