Andy Swiffin wrote:
> However as regards ePPN we seem to be going round in circles. If it
> is legitimate to use some other identifier then we can consider that
> and may be able to sign rule 6, otherwise I think not unless we go
> for a change of policy and put some work in.
I'm sorry if I have introduced more confusion than was strictly necessary.
eduPerson says this:
> Definition The "NetID" of the person for the purposes of
> inter-institutional authentication. Should be stored in the form of
> [log in to unmask], where univ.edu is the name of the local security
> domain.
>
> Notes If populated, the user should be able to authenticate with this
> identifier, using locally operated services. Local authentication
> systems should be able to adequately affirm (to both local and remote
> applications) that the authenticated principal is the person to whom
> this identifier was issued.
Because this is the common definition of eduPersonPrincipalName, you
should use this definition if you can.
However, we recognised that this might cause trouble for many people and
as a result the Technical Recommendations for the federation are less
adamant:
> 7.1.4 eduPersonPrincipalName This attribute is used where a
> persistent user identifier, consistent across all services, is
> required and typically corresponds to the identifier which a user
> presents when authenticating to local institutional services (i.e.,
> the user’s single-signon name or “netID”). The attribute is
> single-valued and structured as a scoped attribute, with the form
> [log in to unmask] The security-domain component has the
> same semantics as the corresponding component in
> eduPersonScopedAffiliation. The local-name is guaranteed to be unique
> within the context of the security-domain. It is recommended that a
> value of eduPersonPrincipalName previously associated with one
> individual should never be reassigned to another individual.
> Non-reuse may be assured by deriving eduPersonPrincipalName from a
> (non-repeating) staff number or student matriculation number, though
> care should be taken to ensure that any implicit information is not
> inadvertently leaked; for example, age may be encoded as part of the
> matriculation number. As in the case of eduPersonTargetedID, users
> and service providers should be aware that identity providers may not
> always be able to guarantee to present the same value of
> eduPersonPrincipalName.
(note the "typically" in the above)
So, I'm really saying both that you *should* probably reconsider your
policy of reallocating local user IDs, but that in any case it *is*
acceptable for you to derive your ePPN values from something other than
the local user ID if that's what you need to do to meet the non-reuse
constraint.
-- Ian
|