Understanding Shibboleth Identity

[Joshua Riffle]

Our university developers have been exploring what a Federated ID would be
for our accounts. So far we basically understand it needs to be a
meaningless (won't need to be changed after the account is created), unique
attribute with lots of space. I was attracted to EduCause's
eduPersonTargetedID (which is unique for the user within the scope of the
Service Provider):

*Definition*

A persistent, non-reassigned, privacy-preserving identifier for a principal
shared between a pair of coordinating entities, denoted by the SAML 2
architectural overview [1] as identity provider and service provider (or a
group of service providers). An identity provider uses the appropriate
value of this attribute when communicating with a particular service
provider or group of service providers, and does not reveal that value to
any other service provider except in limited circumstances.
http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200712.html

The problem with using eduPersonTargetedID is that it is persistent ID
created by the Identity Provider when it communicates the user's attributes
to the Service Provider and not stored in a directory or database. So what
do you do if you want to manually provision only the user accounts on the
Service Provider that will be allowed to access that service? Is there a
way of exporting a bulk list of eduPersonTargetedID's from the Shibboleth
IdP for a list of specific users like you would if it was stored in a
directory?

I sense this approach to handling Shibboleth Identity may be flawed so I
would love to hear stories from other users who have implemented their own
federated ID or used the eduPersonTargetedID attribute.

Joshua Riffle
Software Engineer
*Azusa Pacific University*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120911/0116b52f/attachment.html