20 likes | 295 Views
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.
E N D
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 multi-tenant 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. Recipe for a Reverse Proxy using SAML and UMA
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-saml-and-uma/