I agree with Alan, I would like to know a representative use case where SAML assertions have to be rewritten by intermediate proxys It is not only a problem of delay, and deployment complexity. It a problem of semantic about SAML assertion. The question is: What kind of attributes will be placed in the assertion that need to be rewriteen? As far I know SAML assertion should carry on information about the end user (information about the network should be transported in RADIUS attributes) so I don't see what is the purpose of rewriting that.
Best regards, Gabi. El 15/03/12 21:31, Alan DeKok escribió: > Sam Hartman wrote: >> so, I think you may be missing what Jim is asking about. Jim is talking >> about a proxy that wants to radically change the SAML assertion being >> carried. We think the only way to do that is for the proxy to act as a >> client, grab the entire SAML assertion using the fragmentation protocol, >> then originate an assertion of its own that it fragments and passes >> along. > Yeah... It's possible, but I'm scared of that. > > It involves changing the design assumptions of many servers. Proxying > would no longer be an event / packet-driven mechanism. Instead, the > inputs and outputs would be largely decoupled. > > It could also greatly latencies in the network. What happens when you > have 2-3 layers of proxies, and each wants to change the SAML > assertions? Instead of one client-server latency, you'd have 3 times > that, due to the sequential nature of the proxying. > > My take is that proxies which do re-writes SHOULD pro-actively request > the authorization data. This would mean watching the Access-Accept for > a "more authorization" flag, and the immediately requesting the > authorization data. That data would be cached locally. > > When the client requests the authorization data, any response would be > delayed until all of the data was available. Then, the re-write would > occur, and the response sent. > > This design simplifies the proxy implementation. Instead of having to > juggle multiple packets, it just sends back a cached response. Since > servers already send back canned responses, we know that the design works. > > Alan DeKok. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel Lpez Milln Departamento de Ingeniera de la Informacin y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: [email protected] _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
