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.
Sure, I got that part :)
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.
So, basically we are saving some time, so when the client requests the
data, the proxy may already have been received some fragments (may be
not all) from the server. This reduces latency, but depending on the
number of fragments, the client may need to wait anyway and think the
proxy is unresponsive.
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.
Yes, but that should be done pro-actively or re-actively, either way.
The only difference is what is triggering the several roundtrip exchange
to retrive the data. In the pro-active mode is the presence of the
Authorize-Only service type, indicating that *probably* the client will
request for authorization data. In the re-active mode, the trigger is
the actual Access-Request from the client requesting the data. Am I wrong?
An explicitly decoupled approach can be simpler. I wouldn't say it's
a requirement. I would say it would be my preferred implementation.
That's something I don't really know, as I never implemented a RADIUS
server. If you say so, I'm completely confident :)
Regards,
Alejandro
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
