>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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
