LDSTechForumProjects

SSO Environment Overview

(Redirected from SSO Simulator Environment)

SSO Environment Overview

The SSO Simulator also known as the WAMulator for Web Access Management simulator, is a standalone tool enabling simulation of the runtime environment seen by applications when running in the Church single sign-on environment. The original environment leveraged the OpenSSO solution. As of mid 2010 this solution was replaced with Oracle Access Manager and Oracle Entitlements Server and their corresponding elements as shown in Figure 1. Inherent in this environment is that all applications appear to be on the same domain server; lds.org for example. Applications then reside at different sub-paths of this domain. These sub-paths are also used to uniquely identify packets associated with that application allowing for routing to the back-end cluster containing that application after it has passed through a web gate.


Figure 1: SSO WAM Environment


For example, https://lds.org/mls/mbr/… identifies the MLS Web member application and all packets headed to URLs starting with /mls/mbr would be routed to the server cluster housing that application provided the user is allowed to access that URL resource. This structure of folding multiple applications into a single domain is known as reverse proxying; all packets intended for a site arrive at some form of http proxy which then routes them to any number of servers. This is in contrast to a forward proxy leveraged by user agents like browsers to access sites to which it can not go directly such as when located behind a corporate firewall.

Reverse Proxying and Enforcement

As shown in Figure 1, traffic to the site is resolved by DNS to hit a load balancer fronting a cluster of http caching devices. These in turn proxy to another load balancer fronting a special reverse proxy known in Oracle Access Manager as a web gate. These web gates look at each request and check to see if that URL is accessible to the user of the request as identified by a cookie included with the request. If the user does not have a currently active session, then the agent must redirect the user to a sign-in page. Upon successfully authenticating, the sign-in service sets a token in a cookie and redirects the user agent back to the original URL whereupon receiving the original request with the active cookie, the web gate now evaluates if the URL is allowed to be accessed by the user. If the user meets any of the conditions for access then the request is allowed onward. Otherwise they are forbidden access.

Canonical Versus Application Space Enforcement

A result of using a reverse proxy approach is that the agent evaluates URLs in what is referred to as the canonical space, the URLs that show in the user’s browser. Applications can or rewriting proxy can rewrite URLs to accommodate some requirements of application implementation technologies. The java context was a notable example. The application residing at /mls/mbr… is a java application and more applications will be coming that will be mapped beneath the mls tier. But java contexts originally had to be a single path level and this application’s java context root happened to be /mls-membership.

When the incoming packet hit the java application server it had better have a path starting with /mls-membership and not /mls/mbr otherwise the web server wouldn't associate it with and pass it into the servlet container for handling. Such URLs arriving at the technology implementation point such as the servlet container and subject to requirements of that technology are in what is referred to as application space. Where a URL has a different form in application space than it does in canonical space a rewriting mechanism must be used to “rewrite” the URL before it hits the application server.

This is a subtle but important point. If enforcement of access were implemented within the applications themselves via a filter in java or a rewrite module in xquery for example, then the URLs used to enforce that access would be application space URLs not canonical space URLs. When problems arise with access to a specific resource and a user calls the help center, GSC, the problematic URL being targeted cannot be compared directly against the URLs configured in policies when using application space enforcement. With canonical space enforcement the URLs seen by the users match those in the policies.

The ClientLib provides support for generating canonical URLs.

User Attribute Injection

In addition to enforcing access to URLs the web gates are configured to inject a number of headers into each request that is passed onward to the application servers. The specific headers that are injected are specified by the policy protecting a URL. Some headers are specified for all policies and hence all URLs. Others are user specific like the policy-ldsaccountid and policy-ldsmrn of a user. The headers injected and their format are outlined in SSO Injected Headers.

Fine Grained Permissions

One such header injected for all requests is policy-service-url. It is an indication of the location of the REST service used by the agent to protect resources as shown in Figure 1. A library of utilities, ClientLib provided by the SSO team allows applications to call to that REST service and evaluate URI access decisions provided by Oracle's Entitlements Server. This enables applications to protect sub-portions of their resources like certain widgets on a page and only include them if the user has proper access. These access decisions are collectively referred to as fine grained permissions.

Application Resource Protection

Developers identify resources within their application that should conditionally be rendered. The developer can assign that resource a URI within the URL space of the application and conditionally render that resource only if the user has been granted access to that URI. Such URIs are simply identifiers unique to the application and are solely for restricting access to a resource. The recommended pattern of URIs in OES is to mirror the URLs of the application but without any scheme, host, or port like: "/app-B/restricted-block". See the respective ClientLib library for your environment for more detail.

For an example of fine grained permission use, application B exposed at https://lds.org/app-B/index wants Bishops and members to see most of its landing page but one summary section should only be seen by Bishops. That section can conditionally be rendered by protecting it by a URI of, /app-B/fg/restricted-block, and then granted by a policy requiring the user to have a position of Bishop.

Application Roles

For another example, application C uses the concept of roles to implement workflows. URNs representing each role can be crafted like, /app-C/role/ip-moderator, and policies are created with a condition requiring the user to be a member of a group. By delegating to the policy server asking if the user can access that URN, the application can identify if the user has that role and act accordingly.

In both of these examples, the greatest benefit of placing the access characteristics in policies external to the application is that the policies can be adjusted without having to redeploy the applications or requiring the application to implement its own security database and management screens. If we wish to broaden the access to the Bishop’s summary to his counselors, that is easily achieved in the policy. If we need to add an additional user to those having the IP Moderator role specific to application C, then we add them to the corresponding policy.

Such roles could be assigned by adding attributes into the ldap store for a user but this is an application role and applications come and go over time. Policies are designed to protect resources as in application B or aggregate those who should have a given role as in application C. As applications change so too will their resources and naturally require adjustment to the corresponding policies.

Cookies and Site Domains

One more important characteristic must be highlighted in Figure 1. The cookie being used in the SSO environment matches the domain of the site. For example, the site is lds.org and the domain of the cookies is configured to be “.lds.org”. Therefore, when requests are made to the site the cookie is passed along with the request by the user agent and identifies the user to the web gate and to the application. If the domain of the cookie does not match that of the site then the cookie will not be submitted and result in a ping pong effect with the request hitting the web gate, the web gate redirecting to the sign-in page since it sees no valid session cookie, and the sign-in page then allowing the user to authenticate again to no avail, and so on.

See Also: SSO Environment Simulator

This page was last modified on 4 March 2014, at 10:59.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.