Understanding Shibboleth Identity

[Joshua Riffle]

I didn't realize I have the option of using StoredID rather than ComputedID
when I create an ePTID so I think that answers 90% of my architectural
question. I started looking for something along those lines when you
pointed out that there wasn't any reason why we can't store our ePTID. It
looks like it's a fairly common use-case to try and use Active Directory's
objectSid (utf8_bin) to generate the ePTID and store it in a separate SQL
database. You're right to point out the database as a single point of
failure issue but in the end that will another risk management discussion.

Joshua Riffle
Software Engineer
*Azusa Pacific University*



On Tue, Sep 11, 2012 at 9:21 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120911/4d43a05a/attachment.html