Understanding Shibboleth Identity

[Cantor, Scott]

On 9/11/12 12:03 PM, "Joshua Riffle" <jriffle at apu.edu> wrote:

>Our university developers have been exploring what a Federated ID would
>be for our accounts.

Define "federated ID". That's not really a well-defined term. It probably
implies things to you that you're alluding to below but haven't stated
outright.

> 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):

I suspect EduCause would flee from taking credit for that attribute
anyway, but it's an eduPerson thing.

>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.

Who says it's not stored?

> 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?

If you want to do that, probably the best option is not to generate them
via hashing and instead of generate them in a database. The fact that LDAP
is a lousy place to manage them is a reflection of LDAP's limited data
model, not the concept of a directory or database.

What we see in practice is that presupposing that people will deploy a
database with their IdP is a non-starter. But it depends on your
requirements and your tolerances. I'd love to have a database I could
depend on, but getting one that's not a single point of failure in my
environment is somewhat tough. I hope for others' sake their environment
is not the catastrophic nightmare mine has always been. (Go Bucks.)

>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.

There are definitely sites managing them in a database.

The problems with directed identifiers and ePTID specifically go beyond
this issue. Their size and complexity has been a major problem, with
little adoption by major services (or adoption that works badly). The
provisioning issue isn't so much the one you have, but the fact that other
users can't provision their colleagues because the identifier isn't known,
resulting in the need for introduction/invitation workflows that reduce
security and increase complexity.

Any time you have an application that displays the user's identifier, you
really have a problem making it work, and that's an awful lot of apps
today.

-- Scott