We at Gluu have been working on a solution for a healthcare SaaS provider for a “reverse proxy” to help them migrate from a home grown web access management solution.

1. RECIPE FOR A REVERSE PROXY USING SAML AND UMA
We at Gluu have been working on a solution for a healthcare SaaS provider for a
“reverse proxy” to help them migrate from a home grown web access management
solution. The driver for the integration was supporting an important customer who
required SAML authentication. However, SAML was not enough. The SaaS provider
used the proxy as the policy enforcement point to ensure data privacy for their multitenant system. So the reverse proxy had to enforce URL access control, not just
enforce that all users were authenticated.
I admit, it seems a little weird to use SAML and UMA together.
One of my questions about this solution is how the OX Authorization Server (AS) will
be able to make polcies based on “user claims” (“attributes” in SAML jargon). How
would the AS even get the attributes? Another bothersome question, if the Person is
using a SAML IDP, where is the UMA Relying Party (i.e. the client). The solution we
derived was to build a proxy application that acts as the Relying Party, and passes
the user attributes in the HTTP Request.

2. Of course, we don’t want to write any SAML code, so we actually use the Shibboleth
SAML SP and Apache to handle the authentication and SAML attribute request. If you
think about the flow:
http://example.com –> Shib authentication
http://example.com/oxProx –> Oauth2 session established
web access management solution
http://example.com/oxProx/App1 –> UMA policy enforcement via the Resource Server
The AS could also handle “enrollment” of new users for “just-in-time” provisioning.
Article Resource:-http://gluu.jimdo.com/gluu-blog/recipe-for-a-reverse-proxy-using-samland-uma/