El 28/11/11 16:53, Josh Howlett escribió:
- NAS sends new Access-Request (somehow) tied to the original session
- this Access-Request contains
Service-Type = Authorize Only
State from original Access-Accept
- server replies with Access-Challenge / Access-Accept
- packets contain SAML data
- if the reply is an Access-Challenge, the NAS sends
another Access-Request
Yeah, we had in mind something very similar.
Likewise. I was going to propose something very similar to this for the
Abfab Assertion Request Profile, so that the RP is able to obtain an
assertion from an IdP at some point after authentication.
I'd like to use the same mechanism for both post hoc assertion request and
delivery of jumbo assertions (where delivery of a jumbo authentication
assertion is essentially the case where the assertion is not necessarily
solicited and happens immediately after authentication.
Agree
So I think we should try to decouple the RADIUS/EAP authentication
roundtrips from the RADIUS/SAML assertion roundtrips, modulo some
mechanism to tie these together.
How are you thinking decoupling them? Performing the RADIUS/EAP as usual
(not SAML related data), and let the RP to start afterwards an
"assertion request process" to obtain the authentication assertion?
There's another wrinkle that hasn't been discussed, which is that the SAML
Request may also be larger than 4K. So we really need to deal with jumbo
messages in both directions, which makes this even more interesting
although I think that Alejandro's proposal works in this case.
We also discussed this. Although a jumbo SAML Request is possible, it
would be really unlikely. The main reason to really think about jumbo
SAML messages was, I think, that it is impossible to foresee the amount
of SAML Attributes that will be included in the Response. The request,
however, should not be that big if certificates are not included on it
(as pointed out by Scott). Anyway, I agree that, to avoid problems in
the future, we provide for this functionality.
I think that the "more SAML data" attribute proposed by Alan would work
also if included in requests. In such a case, the AAA/idP could send an
Access-Challenge message (including User-Name and State attributes, for
example), waiting for more data to come from the RP.
Additionally, the "more SAML data" could contain some kind of "cookie"
or "nonce" value, in such a way that if returned unmodified in the
following Request/Response message to the creator, it allows to tie all
the messages within a conversation, if other means (e.g. State
attribute) are finally not enough or not applicable.
Regards,
Alejandro
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
