Thanks Ian,
the rules are clear and no problem with them. It was the technical
implementation of the rules wrt Shibboleth profile.
So it's the value of NameIdentifier.
The way I see it, the logging is a uk federation extension to the
Shibboleth profile so it would make sense to document the procedure for
fulfilling that clause. Whether it's automatic (unlikely) or via some
documented inter-entity process, e.g. "SP admin should email value of
NameIdentifier to technical contact at IdP, who should respond with
whatever user details are required".
That's another Q - how much user information to release to the SP admin?
Should it be released to the SP admin or should the IdP "deal with the
situation"?
Should the IdP respond with user information or should it just tell the SP
that the complaint is being investigated?
In this sense, IdP and SP mean the respective organisations.
Alistair
--
mov eax,1
mov ebx,0
int 80h
> Alistair Young wrote:
>
>> Is this process of user identification via sessions documented anywhere
>> in the fed tech docs? Shibboleth doesn't support SAML2 so it would be
>> nice to know exactly what is meant by talking of session ids that
>> identify users. This sounds like it's an addition to the Shibboleth
>> profile that's specific to the uk federation, so it must be documented
>> somewhere?
>
> It may well be that we could clarify the wording in the Rules of
> Membership. Rhys was quite right about the intention, though:
>
> When your IdP sends an authentication assertion to the SP, the subject
> is identified by a transient opaque name identifier for later reference
> (for instance, in the attribute query that usually follows). This is
> the thing that in early Shibboleth was called the handle.
>
> What the Rules are asking for in 6.5 is that the identity provider logs
> sufficient information such that if a service provider comes to you
> investigating (for example) misuse of their service by one of your
> users, that you can figure out which user that handle represented.
>
> The idea is that this is about user accountability. Users can't be
> accountable if they are completely anonymous to *everyone*. The
> compromise here is that they are anonymous to the service provider
> (known only by an opaque transient handle) but *not to the identity
> provider*.
>
>
> Does this make the intention clear? If so, do the rules (in retrospect)
> now make sense, or can you think of a way that we can clarify this? We
> can make clarifying changes to the technical documents fairly easily;
> the rules are harder, of course, because they are a legal agreement that
> many people have already signed. But, in theory, they could be improved
> too.
>
> -- Ian
>
|