Re: [abfab] EAP naming attribute document

[Josh Howlett <[e-mail]>]

>My bad - I meant to type  -- What happens if AAA transports back two
>different SAML assertions.  I am still getting statement and assertion
>confused.

A statement is basically a strongly typed value. An assertion is an
envelope for >0 statements that provides the rest of the context; who does
those statements describe, who is making the claim, how long is this claim
valid for, etc.

>What I am looking at is draft-howlett-radius-saml-attr, it is currently
>documented as saying that all of the data bytes of all of the Radius
>packets
>in a AAA message are concatenated together.  This means that it is not
>possible for two SAML assertions to be returned (successful) in that the
>second one would be appended to the first one and you would basically have
>two XML constructs concatenated.  One could either modify that draft or
>modify the XML parsing code to deal with two SAML assertions being
>returned
>but that is not presently stated.  Thus I believe that only one (the
>first)
>would be successfully found and parsed under today's specifications.

draft-howlett-radius-saml-attr transports SAML protocol messages. A single
protocol message can certainly contain >1 assertion.


>However (Scott please help me here), in Beijing I was informed that for
>the
>use case that I had it would be possible for the IDP to next a SAML
>assertion from a different issuer within its own assertion.  I don't know
>the syntax that would be expected to ensue (but I really do want to know).

It's certainly possible to do that using the <Advice> element (see 2.6.1
of SAMLCore). I don't know whether it makes sense for your use case.

>> 
>> 
>>     Jim> 5.  Are we defining a property in the GSS EAP namespace that
>>     Jim> can contain the set of attributes that the service wants to
>>     Jim> have returned by the IDP?  This could take the value of the
>>     Jim> SAML Request to be sent to the IDP.
>> 
>> It's my understanding we are not currently doing that.
>> I'd prefer to have someone say that they would implement before we spend
>> energy specifying this.
>
>Plasma is probably going to want this as soon as we start implementations.
>The current concept is that the service is going to ask the IdP for the
>set
>of attributes that it needs to evaluate the set of policies applied to a
>message.  The expectation is that one would not wish to send all
>attributes
>that might be needed to evaluate random policies in generation.

You can trivially specify the required attributes in an <AttributeQuery>
message issued by the RP to the IdP, using draft-howlett-radius-saml-attr.

(The Moonshot GSS EAP implementation doesn't currently support an
application to signal its attribute requirements, mainly because as Sam
implies (I think) the GSS API doesn't currently support this; but a local
AAA proxy that knew the application's requirement could inject this. I
believe it would be better for the application to do this, though)

>Additionally it is expected that SAML assertion issues might map
>statements
>from their space onto the service providers space.  Thus this is something
>that should become important to me quickly.

I think that's an implementation issue.

(FYI, the Moonshot implementation supports this; one of the benefits of
using Scott's SP)

Josh.



JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG