On 2/28/14, 6:47 AM, "Gabriel López" <[log in to unmask]> wrote:
>
>Two models are described in draft-abfab-aaa-saml:

I wasn't describing anything in the context of abfab, merely SAML. I don't
see that abfab has anything to do with dictating how one might do this. It
can provide options, but that's it.

>The draft points out that if the RP issues an authentication request
>(SAMLAuthRequest) to the idp, this request must not include a Subject
>element (to identity the end user). And the idP must make use of the
>inner RADIUS end user identity (UserName), used to authenticate him, in
>order to identity the end user associated with the SAMLauthRequest.
>However, it is not clear for me (maybe I missed something) what value
>(if applicable) must be present in the Subject element of the
>SAMLAuthnSt. assertion to be sent back to the RP.

That's not in scope, nor is it in scope normatively to require any
particular attributes. The relationship between the RADIUS identity and
the SAML identity is a mapping, so by definition cannot be normatively
proscribed.

The same is true moving between any two technologies that use different
representations.

Now, if you want to define a SAML NameID format referencing RADIUS, then
you could create a normative relationship.

But this is all really off the point, see below.

>Obviously if the idp includes the UserName value then the idp is
>revealing the end user identity to the RP, which is not desired.

That depends on the use case. Most of the time, it's probably not only
desired but required.

>The case of an Attribute request it is not explicitly described in the
>draft. I guess that if the RP issues an SAMLAttributeQuery, this
>sentences must not include the end user id in the Subject (following the
>same rules described for the authn request).

Not true, I suspect, and definitely not true in the context of SAML
queries, which is all I was referring to. In general an attribute query
will always identify the subject via a NameID, because nothing else is
really available to do it.

> Again, in this case, the
>idP must make use of the RADIUS end user identity to obtain the end user
>attributes and construct the saml attribute statement. As before, it is
>not clear for me what value (if applicable) must be present in the
>Subject element of the assertion to be sent back to the RP.

The IdP here is a SAML IdP, has nothing to do with RADIUS or ABFAB. And I
was positing a *local* IdP/AA anyway, not a federated one.

I think you're confusing the general with the specific. All I was talking
about was a way to take advantage of the SP code at the RP to do local
lookups of information based on the information obtained from the remote
org.

-- Scott