On 2/28/14, 10:53 AM, "Gabriel López" <[log in to unmask]> wrote:
>
>I'm thinking in the use case where the end user provides the RP
>something like anonymous@realm during the moonshot authentication,
>having the impression of accessing RP with pseudo anonymity. If latter
>the RP is able to see the end user real identity then ......
>In general, I think this use case should be clarified.

More often, that's really a response to the IMHO inappropriate use of
usernames for realm discovery. A user might enter that not to avoid
revealing identity after logging in, but to avoid it before logging in so
as to give local policy a chance to run. For example, I might have a
privacy system where I tell my home realm what RPs to release my identity
to, and if I have to enter that identity to even get the login to start,
that obviously breaks things.

But pretending users would ever enter anonymous@realm is fantasy. Users
don't get that. They will either learn how to enter domains alone, or
they'll pretty much always give their identity away up front.

But I agree, this is an issue more generally. I'm not positing any
specific reveal of user identity. For example one could have group-based
lookup of a shared identity locally via LDAP or SAML.

>ok, then I think abfab-aaa-saml should deal with this use case. What
>NameID it is expected to appear in a SAMLAttributeQuery from a RP if it
>doesn't know the real end user identity?

The case being discussed was a local use of SAML, so this doesn't have to
be talked about, really. As for the federated case, the answer is that if
you want to do this, you use transient IDs, same as today in SAML.

>sure, i'm not talking of a federated one neither, just a home standalone
>radius server and a home standalone idp, which interact to provide
>attributes to the radius server.

But you're talking about "home". I'm talking about something local to the
RP.

-- Scott