Enterprise Identity Bus Part 2

English on February 19th, 2015 No Comments

The first step: Integrating in-house applications into a SSO system leveraging WSO2 as the identity server.

In the last article we introduced the project requirements to get rid of an application identity silo environment and to introduce an identity hub infrastructure. In this blog we are going to tackle requirement A.

A. Single Sign On for in-house applications: A classical WAM discipline involving policy agents installed into application servers, web servers and/or reverse proxies. These agents act as a policy enforcement point (PEP) which check for authentication, redirect to a central login application for authentication, validate sessions and access policies (authorization).

identity-hub-blog-2-enterprise-sso
Searching through the WSO2 web site and documentation, you will quickly realize that WSO2 does not provide much help here. There are SAML agents written in Java which can be used with all WSO2 products and other J2EE web applications. But using access policies powered by the WSO2 Identity Server XACML entitlement engine is only available as something like an experimental feature. And you will be totally left out in the rain integrating content running on web servers or in reverse proxy architectures. That being said there is definitively the need to surf the internet and have a look for other options available.

If you are looking for SAML there are some community Apache modules available. In our use case we decided to go with OpenID Connect for in-house applications because it is based on OAuth 2.0 and as such can be easily used to provide OAuth access tokens to applications protected by a reverse proxy (e.g. through headers). We found open source mod_auth_openidc, developed by Hans Zandbelt / Ping Identity, licensed under Apache license.

Let’s continue the road: All we needed to do was to let the Apache module speak OpenID Connect to the WSO2 Identity Server. Sounds like a quick thing – we are using standards – but turned out to be work mainly due to the incomplete and buggy OpenID Connect implementation in WSO2 Identity Server 5.0.0. Several code modifications were necessary at the server side and as a side effect in the Apache module. Having done that we had a working SSO between the Apache proxies and the WSO2 IS but no authorization. We added the option to configure a “Require entitlement” in addition to the “Require valid-user” and “Require claim” directives already available in mod_auth_openidc. When this directive was activated the agent queries the WSO2 SOAP XACML entitlement interface checking the authorization for specific resources.
With that in place we were able to do single sign on between the in-house applications and protect the URLs with XACML formulated policies, centrally managed at the WSO2 Identity Server.

Requirement A accomplished. Read part 3 of this article for other requirements.

Tags: , , , ,

No Responses to “Enterprise Identity Bus Part 2”

Leave a Reply

You must be logged in to post a comment.