Alejandro Perez Mendez wrote: > I do not see how this simplifies the flow. The number of messages are > exactly the same, and there seem to not be much difference on the amount > of state to be hold either. As I understand, the only difference is the > pro-active nature of the request by the proxy.
The issue is that the proxy needs to have ALL of the SAML data before it can rewrite ANY of it. Since the SAML data is spread over multiple packets, the current near-stateless approach won't work. i.e. current proxies apply the same rewrite rules to every packet. They don't change packet N+1 of a stream based on data seen in packet N. > What's the difference of doing that pro-actively or just waiting until > the Access-Request from the client requesting the authorization data > passed through the proxy? Latency. When a client sends the first "get more data" packet, the proxy CANNOT respond until it has ALL of the SAML data from the home server. This may take a large number of round trips. During those round trips, the client is waiting for a response to ONE packet. The client will think that the proxy is unresponsive, or just very slow. Also, current proxy implementations are largely event-driven. They receive a packet from a client, proxy it, receive the response, and send that to the client. Changing the implementation is hard. Changing it so that the event loop becomes "receive one packet, send many many packets" can be challenging. An explicitly decoupled approach can be simpler. I wouldn't say it's a requirement. I would say it would be my preferred implementation. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
