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.
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.
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?
Regards,
Alejandro
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
