Learn How to Define Customized Polices and Improve User Experience November 25, 2009,
Volume 141, Issue 4
prevent unauthorized access to applications with OpenSSO Policy Agents by defining authentication and authorization policy configurations on the OpenSSO server
Learn how to configure the OpenSSO server and its Policy Agents to use IP/Resource/Environment-based authentication for a flexible mechanism that can define customized policies and improve user experience for access control. The three-part article series hosted on the Sun Developer Network comes from the minds of Qingwen Cheng, Mrudul Uchil and Rick Palkovic, who assume the basics of OpenSSO services (especially Authentication and Policy services) and Policy Agents are understood and installed.
The introduction explains the two-phase process used by OpenSSO Policy Agents (Web or Java EE agents) for restricting access to web resources. Phase one is authentication and phase two is authorization. An IP/Resource/Environment-based authentication design allows for a single point of entry versus a two password required approach and overcomes the limitations of a Gateway servlet approach, such as limited policy condition support, inability to work with a distributed authentication component and the inability to handle federation use cases.
Links to downloads for OpenSSO Express build 8 and OpenSSO Policy Agents are incorporated in the article, along with an illustration and detailed description of the resource authentication architecture and information flow.
This first article tells readers how to create policies for protected resources and add a policy condition to a policy definition.
In this article, three use cases are employed to show how to use Web SSO:
Case 1 involves an enterprise SSO deployment with one OpenSSO instance as the authentication authority and applications that are protected by agents. In this use case, access to the application is based on client IP address. If the client is connecting from an intranet, LDAP authentication is sufficient. However, if the client is connecting from the internet, a strong authentication scheme like Safeword is required. This case is complicated by the fact that multiple applications may exist, each of which must be protected by an agent, and each of which requires a different type of authentication. The procedure provided explains how to solve this use case with new Resource/Environment/IP Address condition, without the need to perform default authentication first.
Case 2 also involves an enterprise or corporate SSO deployment with one OpenSSO instance as the authentication authority and applications protected by agents. Here, various devices, including smart phones, could be used to access an application. Because each device has different capabilities, the enterprise wants to choose an appropriate authentication type based on the device (i.e. Kerberos, UID/password, etc.) The procedure used in this example explains how to solve the situation by enabling environment parameter-based authentication.
Like the prior two, Case 3 involves an enterprise or corporate SSO deployment with one OpenSSO instance as the authentication authority, however there are multiple applications protected by agents and each application has a different look and feel based on the client accessing it when redirected to OpenSSO Authentication. In this use case, access to an application is based on client IP address. Each application customizes its UI based on the client's access location, and this UI customization is linked to the realm-specific Authentication UI customization in the OpenSSO server. As a result, as various clients access an application or resource, they may authenticate to a different sub-realm. The sub-realm is determined by the realm policy condition defined for each application or resource in the policy rule. The procedure provided here describes using Resource/Environment/IP Address condition to solve the dilemma.
Two more use cases are used in this article that demonstrates how OpenSSO handles federation management.
Case 4 is characterized by a federated (SAMLv2) SSO deployment with one OpenSSO instance as the identity provider (IDP). There is only one service provider (SP) instance, which may or may not be using OpenSSO, and the applications are protected by agents. In this use case, the user accesses an agent-protected application and is redirected to the SP Single Sign-on initialization URL by the agent for authentication. The SP redirects the user to the IDP for SAMLv2 SSO with proper authentication context in the request. The IDP then redirects the user to the appropriate authentication service based on the authentication context. In order to authenticate with the IDP, the enterprise would like to choose an authentication type based on client IP address. Because the URL for the original SP application is not passed to the IDP due to privacy restrictions, the IDP must perform an application-specific login from authentication context and user IP address alone.
Case 5 uses a federated (SAMLv2) SSO deployment with one OpenSSO instance as the SP, only one IDP and the applications are protected by agents. If a user accesses the agent-protected application from the intranet, the agent sends the user to local login (UI/Login). If a user accesses the agent-protected resource from internet, the agent redirects the user to an IDP for login through SAMLv2 SSO.
[...read more...]
News and Solutions for Users of Solaris, Java and Oracle's Sun hardware products
Just the news you need, none of what you don't –
42,000+ Members – 24,000+ Articles Published since 1998
prevent unauthorized access to applications with OpenSSO Policy Agents by defining authentication and authorization policy configurations on the OpenSSO server
Print
Email
Enabling IP, Resource, Environment-Based Authentication With OpenSSO
(this article)