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. > 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. > 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? > 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" - 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 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. 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
