On Dec 9, 2011, at 3:11 PM, Alan DeKok wrote: > Klaas Wierenga wrote: >> Apologies for reopening a discussion that seems to have concluded (my only >> excuse is that I was hovering most of the last 2 weeks 20 meters below the >> surface of the Red Sea). >> But I still need some more convincing that we MUST carry the SAML data over >> AAA. It seems to me that using the AAA fabric just to introduce the parties >> to each other and do additional attribute exchange out-of-AAA-band has a >> number of advantages, most importantly, no issue with the 4k limit. I find >> the argument that intermediate nodes may need to rewrite attributes not very >> convincing, after all there are many hub-and-spoke federations in SAML-space >> that do just that routinely, no need for AAA intermediaries. > > I agree that intermediate nodes do not need to rewrite the attributes. > > There may still be benefits from using AAA. The simplest is using one > technology for everything.
yes, that argument I buy, and is in fact the only compelling argument I was able to come up with. > The alternative is to put the SAML attributes in HTTP (everything over > HTTP), and give a URL to the end host. This brings additional issues of > copying the data from AAA server to HTTP server, authenticating the > client which gets the SAML data, securing the data transfer, etc. Well, aren't the SAML IdP and RP already involved? The SAML entities would act as some sort of Authentication Server backend, Active Directory with a callback…. Is it likely that we will have a AAA-only RP or IdP rather than a generic IdP/RP? I think that in particular for the IdP that is an unlikely scenario, it will most likely also support HTTP. And rather than seeing it as a URL I would like to regard it is a endpoint identifier. I don't care for HTTP in particular, presumably this could be a case for SAML-ECP… Klaas _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
