Hi Alan,
thanks for you quick response. Our mail was just a first attempt to
provide a solution. I agree that some details were not described, or
even thought. See my comments below.
Alejandro Perez Mendez wrote:
we have been discussing this topic internally, and we see another
alternative for this. We could define a new RADIUS attribute which
indicates the total length of the SAML Message to be received (for
example, we could call it SAML-Message-Length). This attribute would be
included in the first RADIUS message containing SAML-Message attributes.
That could work. I'm concerned about the possibility of conflict.
i.e. the first packet says "10K SAML data", but the total length of the
SAML data is != 10K.
Right, that kind of situations must be avoided. Anyway, the AAA server
would discard or send an error message on any Access-Request received
when no additional SAML data is to be sent.
When the RP receives this attribute, it knows how many SAML data is
expected from the AAA/IdP and therefore, if the total length of the
received SAML-Message attributes is less than expected, it means that
the message has been truncated and that more data is to be retrieved.
It would be simpler I think to just have an attribute saying "more
SAML data". If it's in an Access-Accept, the client asks for more data.
That means that the processing flow is the same for the first
Access-Accept, and for any subsequent Access-Accepts.
Yes, that would also work.
Then the RP would send an Access-Request message to the AAA/IdP
requesting more data. The AAA/IdP replies with more SAML-Message
attributes. As the RP already knows how many data is to be received,
this process is repeated until the whole SAML message has been received.
That could work...
It has to cost of defining a new RADIUS Attribute, but the advantage
that it does not modify the RADIUS or SAML protocols.
There are additional issues not discussed here.
How do you tie the packets together?
As you say below, the State attribute would do the work. Additionally,
the "more SAML data" could contain a reference, and be included in the
following Access-Request message. Though I think the State attribute
would be enough.
What do you think? Do you think it is reasonable? We could elaborate a
more detailed description if you find it interesting.
What is already done is to use "Service-Type = Authorize-Only". See
RFC 5080 for a discussion.
- user authenticates
- final Access-Accept contains a State attribute
- final Access-Accept contains an attribute "more SAML data"
-final Access-Accept contains a Termination-Action attribute with the
value of RADIUS-Request
- 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.
Similar things are done already with Access-Request and
Authorize-Only. So that behavior falls within the context of existing
RADIUS practices.
The only new thing here is the use of Access-Challenge in this context.
Another alternative would be the following: after the "more SAML data"
attribute is sent, instead of performing several
Access-Request/Access-Challenge roundtrips, perform several
Access-Request/Access-Accept(more-SAML-data) roundtrips. I don't know if
this procedure would go against something in the standards.
Regards,
Alejandro
My $0.02 is that this mechanism for transporting bulk authorization
data in RADIUS should be defined separately from it's use in SAML.
There have been enough requests over the years for this that others will
find it useful, too.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
