Hi,
Thinking about the 4K limit in the RADIUS payload and the four options outlined
by Josh and the discussion we had in Taipei, I guess we could have a fifth
option: the use of multi-packet RADIUS sessions to transfer SAML data when the
payload limit is reached. This will keep us in RADIUS space and allow for
arbitrary long SAML messages. Of course, this would be an optional behavior,
keeping the current (one SAML message in one RADIUS packet) as the default,
mandatory, one. This approach could even be usable in other potential cases
where the 4K payload limit may become an issue.
From the SAML RADIUS binding point of view this would imply to allow the use
of several SAML messages. In principle, several AuthN statements related to the
same NAI and containing the corresponding attributes.The RADIUS client / SAML
RP would have to deal with them as a single statement
From the RADIUS protocol point of view I see two possible options: making the
server to send successive Access-Challenge responses with the corresponding
SAML messages, or defining a new RADIUS packet type. The first option has the
advantage of being easier to implement, though it implies stretching (probably
too much) the semantics of the challenge loops.
Hi Diego, all,
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.
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.
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.
It has to cost of defining a new RADIUS Attribute, but the advantage
that it does not modify the RADIUS or SAML protocols.
What do you think? Do you think it is reasonable? We could elaborate a
more detailed description if you find it interesting.
Regards,
Alejandro
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
