Shibboleth Developers

[Chad La Joie <>]

Rod Widdowson wrote:
> So what we've got (towards meeting all the above) right now is:
>
> - Use of the same metadata provider (and infrastructure), as the IdP.  
> This should shrink the war distribuion down from 7 Megs to being a 
> handful of classes and a couple of jsps.

The new OpenSAML code for dealing with Metadata should allow a complete 
break between the IdP code and the WAYF code, so the WAR should get even 
smaller, for those that care about that.

> - Ability to load multiple medatata providers and sources (configured in 
> wayf.xml in a way similar to the IdP).

I'd like to see this moved out of the deployment descriptor into a file 
that just lives in the file system and is aware of changes.  That way I 
can add new metadata sources and remove old ones without changing and 
redeploying the WAR>

> - Automatic trimming of which IdP's are displayed (only IdPs which the 
> SP knows about are listed)

Are you doing this with a standalone IdP or one integrated with the SP. 
 If standalone, how do you pass the list of IdPs the SP cares about to 
the WAYF?

> - Use of the SAML_IDP cookie to store a list of recently visited IdPs.  
> If one of the recently visited IdPs can service the SP, then the user 
> never sees the WAYF (this is the same mechanism the WAYF uses in 1.3 
> generalised to using the SAML_IDP cookie and multiple federations).

Like Thomas, I think shooting for a state where the user never sees the 
WAYF is a bad idea.  In my opinion there are enough cases where the user 
needs to change which IdP they are going to that not allowing them to 
see the WAYF will be a big pain.  This is why I suggest using the 
SAML_IDP cookie to bubble up probable IdP choices to the top of the list.

> At this stage if one postulates a SAML_IDP cookie aware SP and possibly 
> a mechanism to manage the SAML_IDP cookie (maybe a browser plugin?) then 
> we should get to a situation when the user only sees the WAYF when they 
> genuinely have to set about discovering a new Identity Service.

I keep wondering why a plugin is a good idea for managing the contents 
of a cookie.  Why not just have a webapp that does it?  That way you 
don't have to maintain plugins for every browser on every platform, 
worry about browsers that don't allow plugins, or worry about teaching 
users how to use a browser plugin.

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124