Follow-up on question that I recently asked on the users list about name ID support in Shibboleth IdP

[WULMS Alexander]

I guess there are two main cases:
-One whereby the IdP has to respond to an incoming name-id management request. 
-The other whereby the IdP would need to generate an id-management request.

I believe that both cases can be supported based on one of the front-channel bindings.

The first one could be handled similar to an authentication request; the IdP parses the name-id management request, stores it into an internal structure and then invokes a (custom) plugin (configured through for example the handler.xml file) to really process it. The plugin logic can then interact with the user-store (a little bit like an authentication plugin), redirect the browser (hence need for front-channel binding) to some custom UI page or whatever if needed and eventually return control to the IdP via an API call (again, very similar to the authentication plugin). The IdP then generates the name-id management response and returns it to the browser, which can then submit it to the relying party that made the request.

For the other case it is indeed more tricky. It really moves into the realm of user management. I could imagine that the IdP provides some API, which could be invoked by a custom user-management-GUI. E.g. the Web GUI is developed by the organization that uses Shibboleth and bundled into the idp-installer-web directory, just like a custom authentication plugin and login page. This GUI application can present the user some option to unlink the account or perform other updates that must be synchronized. The GUI application can then invoke the API on the IdP, so that the IdP can start the name identifier management protocol, or something like that. On the other hand, I'm not sure from the Oasis spec if an ID-management request can actually go from IdP to IdP (potentially through a user-agent) or if it goes by definition from an SP to an IdP. In the latter case, the User Management GUI should be an SP-based application that can interact with the local user-store and that invokes the remote IdP through the user-agent, like described above.

Does this make any sense at all?

Thanks and kind regards,
Alex



-----Original Message-----
From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, February 02, 2012 8:04 PM
To: Shib Dev
Subject: RE: Follow-up on question that I recently asked on the users list about name ID support in Shibboleth IdP

> It's certainly not in 3.0 roadmap, that's already (over) full and set.
>  That said, it's something that could be pursued for 3.1, 3.2, etc.
> We would definitely need to think about it a lot more than we have to
> date though.  Theres no doubt a ton of edge cases to deal with to make
> a robust implementation.

Yes. I would add in particular we have no thinking done on when the IdP would trigger those messages and what the source of those events would be, because unlike the commercial products, we don't try to be the repository of identity data, which is where those changes get triggered from.

Part of the feature set (the unlinking in particular) also overlaps with the notion of a "user UI" for manipulating state related to the IdP, which has come up occasionally, and also overlaps with consent management.

-- Scott

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net