>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes:

    >> Is the proxy's state required any more than the state a server
    >> needs to retain for its outstanding fragmented requests?

    Alejandro> No, it should be the same. But it would be more than
    Alejandro> usually required for a proxy (they usually receive, send
    Alejandro> and forget). Anyway, I'm not sure that is actually a big
    Alejandro> issue. I was just asking if it was.

I'm greatful that you're trying to explore this issue because I think it
gets at the core of Jim's question. 
I don't know if the state required is too much. Here are my thoughts:

1) It makes rewriting SAML requests significantly more effort than
rewriting RADIUS attributes.  That said, there are a number of ways
(needing a SAML library, possibly needing to resign or strip signatures)
where a SAML rewrite is harder for a RADIUS server than a RADIUS
rewrite.
However this increases state not just adding new libraries.

2) It wouldn't surprise me if proxies near an RP handled similar volumes
of requests as home servers or proxies near an IDP.

3) In a proxy fabric deployment it wouldn't surprise me if proxies in
the middle of a federation handle significantly more volume than proxies
near the edges.


4) In the Moonshot deployment we're hoping to avoid proxy fabric and use
trust router, so we're hoping that any proxy-like entities in the middle
will not see individual requests. I think implicit in that is an
assumption that attributes of individual requests will not need to be
rewritten in the middle.

5) The effort required for this sort of rewrite is very similar to the
effort required to map from SAML and other authorization languages to
Kerberos in the gss-preauth/eap-preauth cases on the RP's KDC.

In conclusion, I'd be happy if we had more data on use cases and
performance requirements for proxy rewriting.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to