Application Development with Single Sign-On
Presentation given at the 2010 Developer's Conference
In late 2008 the Member/Leader Portfolio of the Church ICS Department began research and implementation of a single sign-on or SSO solution for use with the new labs.lds.org and beta.lds.org web sites. Many applications were under construction that needed to work together, required authentication, and varying degrees of additional conditions on access. The tool selected at that time was Sun's OpenSSO open source product. The labs.lds.org site went live with this SSO solution mid 2009 and beta.lds.org followed in December of the same year. Various tools were crafted along the way to facilitate development of applications and simplify interaction with the SSO environment. Some time mid 2010 the enterprise version of SSO will become available but is based upon Oracle Access Manager and Oracle Entitlement Server. As we move toward the new solution the same tools will be updated with an eye toward insulating existing applications as much as possible from requiring changes. There is no guarantee on how successful we will be at alleviating all change but the outlook is very positive that the impact will be low. Hence, the technologies outlined in this article, although currently are for the OpenSSO solution, should be applicable in the new environment. I'll keep you posted here as things progress.
SSO & WAM Defined
Lets begin our discussion by first clarifying terms. Specifically, what is SSO? What is Single Sign-On? Before answering I'll further restrict the domain in which I will be defining the term. The domain is that of web applications and web services. As such a more appropriate term in this context is WAM which is short for Web Access Management. In this domain and specifically our implementation, WAM is a layer of http proxies separating protected resources, web applications and web services, from external user agents or applications as shown in the image below. Furthermore, WAM provides something known as a policy decision point (PDP) or policy server. This (PDP) defines and evaluates the access policies for the protected resources. Access can be unenforced by granting to anonymous users, require only authentication by preventing access by anonymous users, or require that in addition to authentication access meet further conditions. Furthermore, access can be restricted to specific http actions like GET, POST, etc.
So the SSO environment looks at any given http resource request, checks to see if it is in available to anonymous users and if so, proxies it onward to the web server that can respond to that request.
If the request is not available to anonymous users then the user agent is redirected to a sign-in page to authenticate and receive a cookie containing an SSO token and representing the SSO session. Then the user agent is redirected back to the original request and policies can then be evaluated to see if the user meets the criteria for access: http action type, authentication only, or authentication coupled with other conditions. Access is then either granted and proxied onward or denied.
When developing applications for use with the SSO environment applications fall into two distinct camps. The first camp is applications running outside of the SSO environment but requiring access to resources protected by SSO. Mobile applications fall into this group. How such applications interact with SSO from this perspective is discussed in External Application Development with SSO. The second camp is applications running within and being protected by the SSO environment. How such applications see and leverage the features of SSO is discussed in Developing SSO Protected Applications.