 |
 |
Andy Swiffin wrote: > Would it be possible to split the requirement rather than lumping > PrincipleName and targetedID together? The short answer is no, the Rules of Membership deliberately bundle various behavioural rules together so that service providers only really have two classes of IdP to deal with (section 6 compliant and "everyone else"). Your saying "yes, we do everything in section 6" is just a simple way for you to convey that bundle of guarantees via the federation rather than having to negotiate with each SP independently. If the bundle isn't appropriate, of course, there is nothing stopping you having a more detailed discussion with each SP you want to deal with. As (we hope) very few of them will need ePPN, that might be viable in some cases. Life is likely to be easier if you can sign up to section 6, though. [lots of good analysis snipped] > Of course this all assumes that PrincipalName is the users actual login > ID - does it have to be? Could it be like the targettedID, some > obfuscated version of the matric/staff code? I think my first observation would be that I'm surprised that frequent reuse of login IDs isn't causing you headaches elsewhere already. But your question here is the critical one, I think. The Technical Recommendations for Participants cover this (in 7.1.4). We are less absolute than eduPerson with regards to ePPN, because we realise there may be issues with reassignment of login names in some institutions . The eduPerson specification is clear that the expectation is that the eduPersonPrincipalName is the identifier used to authenticate the user. The main reason I can see for wanting this to be the case are to do with the user therefore being aware of the value, so that it can be used in out-of-band communications. For example, my ePPN is [log in to unmask] (same as my e-mail address) and I can phone someone up and say "my ePPN is [log in to unmask], please add me to that access control list". In practice, if you reassign login IDs and you wanted to sign up to having stable ePPN values, using some value other than the login ID would work just fine. You probably would want to think about how far you wanted to obfuscate it; if one of your students asks you what their ePPN is for reading over the phone to someone to put into an ACL, you don't want to have to deal with something like this: [log in to unmask] On the other hand, this might be acceptable: [log in to unmask] > Well, yes, but, as Jon pointed out earlier: > > "The Internet2 software only supports hashing on the fly. You can > presumably > extend it, given sufficient Java skill, to support only computing the > value once." > > I'm not sure I feel brave enough to start hacking round with the code > right at the outset.... The good news is that there are various people out there who have already put together systems that work with an external database in the way described. If one of them is listening, pitch in here please! The only reason such a facility hasn't been bundled into the standard IdP is that making it work "out of the box" would require the bundling of an SQL database with the IdP distribution... It does, however, seem like we should be pointing people at one or more standard database-backed implementations of ePTI if we can find some that are well enough documented. Oh, and as a by-the-way, I'd note that some more good news is that as of IdP 1.3.2, the IdP has apparently acquired a nice ability to do random attribute computation in "scriptlets". This might make it easier to put this kind of extension together in future. Documentation here: https://spaces.internet2.edu/display/SHIB/ScriptletAttributeDefinition -- Ian