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.<br clear="all">
<font face="tahoma, sans-serif"><div><font face="tahoma, sans-serif"><br></font></div>Joshua Riffle</font><div><font face="tahoma, sans-serif">Software Engineer<br></font><div><font color="#CC0000" face="tahoma, sans-serif"><b>Azusa Pacific University</b></font></div>
</div><br>
<br><br><div class="gmail_quote">On Tue, Sep 11, 2012 at 9:21 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 9/11/12 12:03 PM, "Joshua Riffle" <<a href="mailto:jriffle@apu.edu">jriffle@apu.edu</a>> wrote:<br>
<br>
>Our university developers have been exploring what a Federated ID would<br>
>be for our accounts.<br>
<br>
</div>Define "federated ID". That's not really a well-defined term. It probably<br>
implies things to you that you're alluding to below but haven't stated<br>
outright.<br>
<div class="im"><br>
> So far we basically understand it needs to be a meaningless (won't need<br>
>to be changed after the account is created), unique attribute with lots<br>
>of space. I was<br>
> attracted to EduCause's eduPersonTargetedID (which is unique for the<br>
>user within the scope of the Service Provider):<br>
<br>
</div>I suspect EduCause would flee from taking credit for that attribute<br>
anyway, but it's an eduPerson thing.<br>
<div class="im"><br>
>The problem with using eduPersonTargetedID is that it is persistent ID<br>
>created by the Identity Provider when it communicates the user's<br>
>attributes to the Service Provider and not stored in a directory or<br>
>database.<br>
<br>
</div>Who says it's not stored?<br>
<div class="im"><br>
> So what do you do if you want to manually provision<br>
> only the user accounts on the Service Provider that will be allowed to<br>
>access that service? Is there a way of exporting a bulk list of<br>
>eduPersonTargetedID's from the Shibboleth IdP for a list of specific<br>
>users like you would if it was stored in a directory?<br>
<br>
</div>If you want to do that, probably the best option is not to generate them<br>
via hashing and instead of generate them in a database. The fact that LDAP<br>
is a lousy place to manage them is a reflection of LDAP's limited data<br>
model, not the concept of a directory or database.<br>
<br>
What we see in practice is that presupposing that people will deploy a<br>
database with their IdP is a non-starter. But it depends on your<br>
requirements and your tolerances. I'd love to have a database I could<br>
depend on, but getting one that's not a single point of failure in my<br>
environment is somewhat tough. I hope for others' sake their environment<br>
is not the catastrophic nightmare mine has always been. (Go Bucks.)<br>
<div class="im"><br>
>I sense this approach to handling Shibboleth Identity may be flawed so I<br>
>would love to hear stories from other users who have implemented their<br>
>own federated ID or used the eduPersonTargetedID attribute.<br>
<br>
</div>There are definitely sites managing them in a database.<br>
<br>
The problems with directed identifiers and ePTID specifically go beyond<br>
this issue. Their size and complexity has been a major problem, with<br>
little adoption by major services (or adoption that works badly). The<br>
provisioning issue isn't so much the one you have, but the fact that other<br>
users can't provision their colleagues because the identifier isn't known,<br>
resulting in the need for introduction/invitation workflows that reduce<br>
security and increase complexity.<br>
<br>
Any time you have an application that displays the user's identifier, you<br>
really have a problem making it work, and that's an awful lot of apps<br>
today.<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br>