Developing Applications for SSO Justen Stepka Authentisoft, LLC

Overview Introduction What is SSO Designing and Implementing for SSO environments Available Solutions

Introduction Justen Stepka Principal and Founder of Authentisoft, LLC. Hibernate  Hibernate documentation manager. O’Reilly Author  Contributing author of Java Database Programming Best Practices  Various articles for the O’Reilly website. JDJ guest writer  Open Symphony Project Overview

The Problem As web-applications have grown over the years to support various business processes. These applications have expanded to support a growing number of users, groups and roles. Most of these applications administration functions are controlled by a small sub-set of internal users that have permissions to access additional functionality where they become the gatekeeper for the security information and application deployment attributes. The burden taken on with the administration grows as the number these systems are deployed.

What is Single Sign-On Different views on what is SSO. Authentication verses Authorization

SSO Definition SSO maintains two definitions, depending what your ultimate deployment goals are: Central repository where username and credential information are kept and then used by all subscribing applications for authentication. When a principal authenticates with a node of the system, they are assigned a token. This token can then be used by other applications to validate the user is who they claim to be. With this token, the principal can then bypass the authentication process.

Authentication verses Authorization Authentication is the process of verifying the users’ identity. Typically this involves obtaining a username and password, other forms of credentials may be used such as scan-cards or biometric devices. Authorization is the process of verifying whether a user has access to a protected resource.

The End Goal Authentication is to be performed in a single pluggable fashion. This will permit your Java applications to remain independent from the underlying authentication technologies. New or updated technologies can then be plugged in without requiring modifications to the application itself.

SSO Benefits Termination of account is cascaded across all applications. Simplified authentication approach. Removes burden of continuously solving the same problem over. Identity information does not have to be replicated between applications. Reduced number of authentication credentials for a principal. Removing the need to remember multiple credentials resulting in replicated passwords.

When to use SSO A single principal store exist for storing principals Active Directory Open Directory Custom database tables 1+n applications Every company is different, it’s about easy of maintenance at the end of the day.

Acme Corporation Example Active Directory Windows environment for the desktop. Database storing customer information. Web inventory management application. Public website where customers order ACME widgets. Intranet applications where company information is posted for employees. Issue tracking software where customers log widget defects. Forum system software where customers receive support for their widgets.

Acme Corporation Deployment Diagram

Acme Corporation SSO Benefits Customers share authentication between the public website, issue tracking, and forum system. Employees are able to access all applications with their Active Directory account.

How Applications are picked for ACME Corp ACME corporation selected Jive and JIRA for the support they offer with integrating third-party authentication systems. Forward thinking applications these days provide authentication interfaces to support external users. Uses an LDAP connector. Provides an interface for implementing custom connectors.

Application and Open Source Call to Arms Interoperability between separate open-source applications will help spread open-source. At minimal provide an LDAP connector option. For smaller corporations, or those running at data- centers, LDAP may be too costly over overkill. Provide an interface option, this is a more elegant and flexible solution.

Designing for SSO When designing an application to support external authentication or authorization, there are a few natural breaks in functionality. Authentication  The process of verifying the credentials provided by the requesting principal Authorization  Determining whether a requesting principal has access to a specific resource through a group or role. Profile Management  The personal details and preferences that are associated with a principal. Resources Management  Creating, modifying, and deleting the security rules and relationships.

Designing for SSO When designing an application to support external authentication or authorization, there are a few natural breaks in functionality. Authentication  The process of verifying the credentials provided by the requesting principal Authorization  Determining whether a requesting principal has access to a specific resource through a group or role. Profile Management  The personal details and preferences that are associated with a principal. Resources Management  Creating, modifying, and deleting the security rules and relationships.

Breaking Functionality Out Breaking functionality out enables wider deployment integration. Not all deployments may be able to support all aspects of functionality. Might be able to support reading authentication and authorization rules, but not able to write to the directory server. Storing profile information would then need to be kept internal to the application. Using an interface system will allow your customers to easily implement their own security architecture into your application.

Interface Examples Examples here are as simple as possible, additional Exceptions often help with workflow related issues. It is important to remember that as you add complexity to an already complex problem, the difficulty with implementing the solution seems to go up ten-fold. An existing interface system that already exist is OSUser which is available developed and maintained by the Open Symphony group at

Authentication Interface public interface Authentication { public String authenticate (String username, char[] password) throws AuthenticationException; public String authenticate (String username, char[] password, HttpServletRequest request, HttpServletResponse response) throws AuthenticationException; public boolean isValidToken(String token, HttpServletRequest request, HttpServletResponse response); }

Authorization Interface public interface Authentication { public boolean isGroupMember (String username, String group); public List listGroups(); public List listGroup(String username); }

Profile Interface public interface Authentication { public void addAttribute (String username, String key, String value); public void removeAttribute (String username, String key); public String getAttribute (String username, String key); }

Management Interface public interface Management { public void addPrincipal (String username, char[] password) throws InvalidPrincipalException; public void removePrincipal (String username); public void changePassword (String username, char[] password); throws InvalidCredentialException; public void addToGroup (String username, String group); public void removeFromGroup (String username, String group); }

Using the Interfaces The simplest approach is to load the implementations off a deployment descriptor using the DAO Factory Model. This allows you to load implementations at run-time, giving you the ability to quickly connect applications to new or existing directory services.

Existing Approaches Open Source JAAS  Java Authentication and Authorization services. JOSSO  Open source gateway connector to LDAP. CAS  Developed by Yale; central authentication service. Commercial IDX SiteMinder Oblix Tivoli