Authentication Service Architecture

Transcription

1 Authentication Service Architecture Open Web Single Sign-On Version 1.0 Please send comments to: Author Mrudul Uchil Architect & Technical Lead

2 This document is subject to the following license: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version ii

3 Contents 1 Introduction Document Status Revision History Summary Scope Context Glossary References Objectives Mission Stakeholders Architectural Concerns Extensible and Customizable Infrastructure Remote Access to Authentication Service Authentication Configuration Administration User Session upgrade or downgrade facilities Protection against Denial of Service attack Availability and Reliability Security Performance and Scalability Monitoring and Auditing Architectural Views Extensible and Customizable Infrastructure View Viewpoint Specification Detail Description Extension Session Upgrade Transition View Viewpoint Specification Detail Description Extension Authentication Client View Viewpoint Specification Detail Description Extension Load Balancer Enabled Deployment View iii

4 Viewpoint Specification Detail Description Extension Authentication Service Conceptual Implementation Authentication Service Software Implementation Authentication User Interface As J2EE web application Functional Query Parameters support Customization Domain cookies management Authentication API Distributed Authentication User Interface Authentication Service Middle tier Different authentication types Redirection URLs Account Lockout Maintain user's login state Generation of User session Session Upgrade Important Objects Authentication SPI Authentication Modules Authentication Configuration Authentication State Structure Session Interface Point Other Services Interface Point SSO Agent Interface Point Internal Request Routing Scheme Security Conclusion iv

5 1 Introduction 1.1 Document Status Project Name Open Web Single Sign-On Document Title Authentication Service Architecture Date of Issue December 22, 2005 Current Version 1.0 Author Mrudul Uchil Issuing Organization Sun Microsystems, Inc. Feedback 1.2 Revision History Date Version Author Comments December 22, Mrudul Uchil Initial Revision. 1.3 Summary The Authentication Service is the point of entry and the first core component in the Single Sign-On (SSO) infrastructure. A user, administrator or client application must pass an authentication process before being granted SSO privileges and allowed access to resources secured by the SSO infrastructure elements. The core function of Authentication Service is to validate the required credentials of end users, administrators or a number of applications accessing information or protected resources in the SSO environment. The Authentication Service facilitates different authentication methods that can be used to authenticate against different authentication mechanisms (modules) in the same SSO environment. This purpose of this document is to provide the architectural details for the implementation of the Authentication Service in the Open Web Single Sign-On project (also referred to as OpenSSO) in satisfying the system requirements and the architectural concerns. The System Architecture Document [2] was used as a reference to write this document. The structure of this document is based on the recommendations provided by IEEE Standard [1]. All the important terms, acronyms, or abbreviations used in this document are defined in the Glossary section. 1

6 Introduction 1.4 Scope This document essentially describes the detailed architecture of the Authentication Service framework in the OpenSSO project. It is not a requirements document although it does reflect the functional requirements addressed by this architecture. The purpose of this document is to provide a certain level of specifics about the Authentication Service framework as well as to serve as an effective vehicle for facilitating any design and implementation practice pertaining to the Authentication Service framework. 1.5 Context The Authentication Service of the OpenSSO system can be accessed via a web browser, by an application using the Authentication client API, or by any other client, that correctly implements the Authentication Service messaging interfaces. When a user or application tries to access a protected resource, credentials are requested by one (or more) of several authentication modules. Gaining access to resources requires that the user or application be given permission based on the submitted credentials. The Authentication Service is the authority, granting or denying access upon completion of the authentication process and credentials assertion. After authentication, the requestor is directed to the requested resource or application in SSO environment. Generally speaking, the Authentication Service should perform some or all of the following actions: 2 Identify requester's credentials requirements in order to grant access. Generate dynamic user interface as per the authentication module being accessed (single phase or multi-phase), to collect requester's credentials. Support above user interface being customized and client-type aware. Support pluggable authentication modules. Create session and session identifiers. Set the requesters's identity information and important characteristic data as session properties in a session. Provide a session upgrade facility. Populate and manage system domain cookies. Provide pre-processing and post-processing SPIs. Implement different success and failure redirections end points. Generate different time dependent alerts and session expiration / time-out notifications.

7 Introduction Provide remote authentication programmatic APIs. Provide authentication configuration management interfaces. Provide user account lockout functionality upon frequent invalid intrusion in the system. Implement load balancer friendly deployment facilities. Provide remote user credentials extraction and submission user interface application for distributed deployments. Implement a clean logout interface with session destroy. A user session is the interval between the moment a user logs in (authenticates) to the OpenSSO system, and the moment the user logs out of the system. Using a concrete use case example, in a typical user session an employee attempts to access the corporate benefits administration application. The application is protected by an SSO Agent, and the OpenSSO system prompts the user for required user credentials as defined by the Authentication Service. First, the Authentication Service validates that the user is a valid user. The OpenSSO system then allows the user access to the application. In the same user session (without logging out of the corporate benefits application), the same employee attempts to access the corporate expense reporting application. The expense reporting application is also protected by an SSO Agent. In this second transaction, the Session Service provides continued proof of the user s authentication, and the employee is automatically allowed to access the expense reporting application. The employee has accessed more than one service in a single user session without having to re-authenticate. This functionality is called Single Sign-On (SSO). SSO is always preceded by a basic user session in which the user is first authenticated, a session is created by the Authentication Service, and the user's session token is validated. SSO begins to occur when the authenticated user requests a protected resource on a second server in the same domain. The Session Service maintains user session information with input from all applications participating in the single sign-on. 1.6 Glossary Administrator A privileged user who is responsible for configuring the system so that it can achieve SSO. API Acronym for Application Programming Interface. This is the interface 3

8 Introduction normally used by clients to programmatically access the server system. Authentication The process by which the identity of a user or administrator is established within the system. This process may involve explicit user interaction with the system outside the scope of any of the web applications that participate in SSO. Authentication Client A client library for Authentication Service. Authentication Level A security Level of Authentication that is associated with every Authentication Module within the system. Higher the Level, stricter the authentication module used. Authentication Module A Module or Mechanism that validates the credentials of authenticating users and administrators against their data repository, within the system. Authentication Service A service that facilitates the authentication of users and administrators within the system. 4 Client An entity that accesses a service within the system. Client Library A specialized component that provides programmatic access to a set of services within the system by acting as a client on behalf of the subsystem that uses it. A client library abstracts the underlying communication and other implementation details necessary to efficiently access the service from within the system. Cluster In the context of OpenSSO, a cluster is a system on which more than one installation of OpenSSO services are available. The systems in a Cluster operate together as a single logical installation. Cookie A mechanism that allows a web server to store some data on the browser that accesses that server. DMZ Acronym for De-Militarized Zone. This the semi-secure zone used in the common deployment scenarios. Domain A suffix used in fully qualified host names that allows the logical grouping of hosts. Firewall An entity that limits access to and from a network based on the configured security policies.

9 Introduction HTTP Acronym for Hypertext Transfer Protocol. This is an open standards based protocol used for exchange of information between web browsers and web servers. JAAS Acronym for Java Authentication and Authorization Service. It extends the Java security model to perform checks based on the identity of the caller. Logging Client A client library for the Logging Service. Logging Service A service that allows a client to create log messages in order to form an audit trail of important events within the system. Naming Client A client library for the Naming Service. Naming Service A service that allows a client to locate other services available within the system. OpenSSO Alias for the Open Web Single Sign-On project. This project is an open source initiative of Sun Microsystems Inc., that provides the foundation of identity services for the web platform. Realm Authentication domain of manageable system entities by defined privileged administrators. Remotable Any entity that has ability to remotely interact with OpenSSO system. SAML Acronym for Security Assertion Markup Language. SAML is an XML based framework for exchanging security information. Service In the context of OpenSSO, a service is an abstraction that represents functionality provided by a subsystem which can be accessed anywhere within the network using appropriate request and response message constructs. Session Client A client library for the Session Service. Session Service A service that provides the ability to associate a user session with a particular user once that user has successfully authenticated. Session Time-out A preset interval of time after which a user session is considered invalidated. A session time-out can be a hard time-out or an idle time-out value depending upon the configuration of the system. SPI Acronym for Service Provider Interface. This is the interface normally used to extend the server functionality. 5

10 6 Introduction SSL Acronym for Secure Socket Layer. SSL provides a means to encrypt communication between two entities in such a way that it becomes illegible to any other entity. SSO Acronym for Single Sign-On. SSO is defined as the ability of a user to authenticate once and gain access to a variety of web application resources that otherwise would have required individual authentication, with each authentication potentially requiring different set of credentials. SSO Agent A minimally intrusive transparent software component that can be added to the access path of a web application to allow it to participate in SSO. SQL Acronym for Structured Query Language. System In the context of OpenSSO, a System represents a complete deployment where various web applications participate in an SSO environment using the identity services provided by OpenSSO. System Stakeholder A set of people who interact with the system at various stages and in different capacities. The system stakeholders could be individuals, teams or organizations. UML Acronym for Unified Modelling Language. UML is a well known modelling language used for expressing architecture, design and implementation details. URL Acronym for Uniform Resource Locator. A URL contains the necessary information regarding the address and access mechanism needed to access a resource available on the network. User The user of the system is an end user who is interested in accessing one or more protected applications that participate in SSO. This user has no administrative privileges and cannot change the behavior of the system for other users. This user may be able to change the behavior of system as experienced by self to the extent allowed by the Administrator. User Session An interval of time for which a user is considered authenticated and the associated identity information is available to all participating web applications in SSO. A user session begins with the successful authentication of the user and ends with the invalidation of session either by a direct action of the user such as an explicit logout, or by indirect means such as configured session time-out or being invalidated by an administrator.

11 Introduction Web Application An application hosted on either a Web Server or an Application server and is accessible via the web using a traditional browser. XML Acronym for extensible Markup Language. XML is an open standards based data markup language used for representing structured data. 1.7 References [1] IEEE Std , IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE-SA Standards Board September 2000 [2] Arvind Prabhakar, System Architecture Open Web Single Sign-On, Version 1.0 [3] Dennis Seah, Use Cases Open Web Single Sign-On, Version 1.0 7

12

13 2 Objectives 2.1 Mission The mission of the Authentication Service is to provide the functionality to request and validate / assert information about an authenticating user against a specific authentication mechanism and create user session that can be validated across all web applications participating in a Single Sign-On environment, upon successful authentication. The focus in the Authentication Service is to enable pluggable authentication modules for different user credentials requirements and create session after successful validation of those user credentials submission in order to establish the fundamental SSO infrastructure by serving a number of critical functions which enable users to authenticate once yet access multiple resources such that successive attempts by a user to access protected resources will not require the user to provide authentication credentials for each attempt. 2.2 Stakeholders System stakeholders are the people who interact with the system during different life-cycle phases, in different capacities, and for different purposes. These could be individual users, teams and organizations that are charted with the development, adoption or execution of this system. The key stakeholders for the Authentication Service are: Developers: Responsible for the overall development of the system. They may be involved in various development related activities associated with the Authentication Service such as designing, developing, building, testing, documenting, and troubleshooting the functionality provided by the Authentication Service. Administrators: Privileged users who are chartered with deployment and configuration of the system in staging and production environments. Administrators can control the system behavior via the available configuration mechanisms at various levels and thus affect the way the system operates. They are expected to perform system checks to ensure its operations and take corrective actions where necessary if the system fails to perform satisfactorily. End Users: Users who access the hosted web applications and do not have any special privileges to alter the behavior of the system for others. Web Application Developers: Developers who are responsible for the creation and deployment of web applications on the network. These developers may use the Authentication Client and other public interfaces in order to make their applications participate in the SSO environment and thus enhance its overall functionality. 9

14 Objectives Web Application Administrators: Administrators who are chartered with the deployment of web applications. These administrators will configure Authentication Client or OpenSSO agents as necessary in order to ensure that the hosted web applications can take advantage of the available authentication services. System Integrators: Developers who are chartered with the deployment of OpenSSO in a given environment to best utilize the Authentication Service. They may be involved in building new SSO agents and using the exposed public Authentication interfaces or Authentication Client where necessary. 2.3 Architectural Concerns There are quite a few architectural concerns which are identified and considered in formulating the architectural concept of the Authentication Service from the perspectives of all relevant stakeholders. While the system wide concerns are already addressed in the OpenSSO System Architecture Document [2], this section intends to focus on the core concerns, which are derived specifically from the system requirements for the Authentication Service Extensible and Customizable Infrastructure The Authentication Service infrastructure must be extensible and customizable in order to allow the creation and integration of customized authentication mechanism (provider) implementations against different authentication credential stores, which can be plugged into the framework to extend the authentication and hence the SSO functionality. These authentication providers can also offer the specialized services tailored to meet different system requirements but have to extend the SPI defined by the authority component of OpenSSO System. The Authentication Service should have a provision for pre and post authentication hooks for customized application logic invocation. For example, this customized application invocation can add additional application specific session properties in a user session upon successful authentication. The Authentication Service User Interface framework should provide the dynamic (single phase or multi-phase) user interface for all supported or plugged-in authentication mechanisms. Also this user interface should be customizable per different realms of OpenSSO System or different characteristics of Web client such as locale or client types Remote Access to Authentication Service The Authentication Service should offer the client libraries by which the user can be logged in (authenticated) and logged out remotely. These libraries or interfaces provided by the Authentication Service should also take care of all the complexities of any underlying transport 10

15 Objectives mechanism, deployments with load balancers, etc. which should be transparent to the clients. The Authentication Service should also provide a remote authentication presentation and extraction framework that can talk to the authentication server internally over the trusted connection using authentication client libraries. This functionality is necessary to protect the secure and sensitive authority component and its data in the secure zone. Giving access to the authentication front end in the DMZ for SSO agents eliminates the need for web clients to penetrate two levels of firewalls in secure deployments Authentication Configuration Administration The Authentication Service should provide the mechanism to authenticate against one or more authentication modules (in the form of a chain) for a given authentication process to be completed by the end user or administrator in order to get access to protected resource in the SSO environment. When chaining of multiple authentication modules is used by the authority granting system, then it must follow some predefined set of rules in order to honor success or failure of each module in that chain. The Authentication Service should also provide the mechanisms to manage the authentication configurations. These administration capabilities may include the creation of an authentication module, the creation of a chain of authentication modules and the assignment of these authentication modules chains to different entities or actors in the OpenSSO system such as realm, user or role User Session upgrade or downgrade facilities The Authentication Service should provide the mechanisms to upgrade or downgrade a user session for new credentials or changed authentication methods information, when invoked by an already authenticated user with an existing valid session but resulting into a different or new higher or lower level authentication methods satisfaction. Once a user session is enhanced and updated with both existing and new authentication authorized data, then the user can access both applications (protected by two different types of authentication statements) without getting prompted for credentials submission Protection against Denial of Service attack The Authentication Service should provide the protective mechanisms against denial of service attacks starting from simple request data size checks to the controlled creation and time-dependent deletion of any dependent objects maintaining state or intermediate session information Availability and Reliability The Authentication Service should provide a function of service continuation, which means the ability to route the user request to the original authority or to the user session creation authentication server even if any network element such as a load balancer chooses to give the request to the incorrect server during single phase of multi phase authentication process. 11

16 Objectives Security The Authentication Service should provide mechanisms to secure the OpenSSO system from password hackers, from secure user credential hackers, and from frequent invalid intrusions. These mechanisms would implement a user account lockout functionality based upon a specified number of attempts by the user to present invalid credentials. A warning would be generated before actually locking the user from entering the system. The number of failed attempts should remain consistent across multiple deployments of OpenSSO applications behind the load balancer. In addition, the submitted user credentials and information required to validate user credentials (in order to create a user session) should be protected by the Authentication Service in a secure fashion. Only privileged system administrators can have access to the respective authentication configuration and validation data, which can be enforced by digital signature verification methods. The Authentication Service should also guarantee that no user credentials information is disclosed in the communication between the Authentication Service and the authentication credentials data stores, as well as between the authentication client and the authentication server. Overall, the system hosting the Authentication service must be protected from unauthorized access Performance and Scalability Given the limitation of the capabilities of the underlying hardware and software components, the Authentication Service should perform and scale up to the necessary levels in order to authenticate, create and accommodate more user sessions. Authentication rate (number of authentications per second) should scale under a heavy load of concurrent user requests Monitoring and Auditing The Authentication Service should provide the facility to monitor the authentication related resource consumption. In addition, Authentication Service should log all its activity events informing user interaction and erroneous conditions, in order to provide the reporting facilities to OpenSSO system applications and users. 12

17 3 Architectural Views 3.1 Extensible and Customizable Infrastructure View Viewpoint Specification Name Extensible and Customizable Infrastructure Viewpoint Stakeholders Developers, Web Application Developers, System Integrators Concerns Extensible and Customizable Infrastructure Modeled As Service Provider Interface, Web User Interface Viewpoint Source System Requirements Detail 13

18 Architectural Views Pluggable Authentication Module Interface Summary Initialize and retrieve the module configuration Retrieve the module's credentials requirements in the form of callbacks Process module specific callbacks for user interaction and submission of required user credentials Validate the user credentials Get the valid user identifier to be added in the user assertion object 14

19 Architectural Views Post-Processing Interface Summary Get control after successful authentication Get control after failure authentication Get control on logout Description In the Single Sign-On environment, an authority granting service like the Authentication Service needs to validate user credentials against the different credentials data stores (wherever user credentials are maintained). A set of service provider interfaces should be defined to allow different providers to write their own credentials validation logic (as authentication module) by extending this interface, talking to respective credentials data store and be able to plug this custom authentication module into OpenSSO system. The OpenSSO system's Authentication Service should provide the web-based user interface for all authentication modules (including custom authentication modules) plugged in the SSO environment. This interface should provide a dynamic and customizable means for gathering authentication credentials by presenting the web-based login requirement pages to a user, requesting access. This User Interface should be highly customizable per different realms of OpenSSO system or per different characteristics of web clients such as locale or client types, as well as at the level of individual display components in each user interface page. Also, in the Single Sign-On environment, all the clients or applications participating in SSO require a handle or hook just after the authentication process is completed and before system exit to invoke / implement application specific logic. The Authentication Service must provide the SPI for pre and post authentication hooks for customized application logic invocation. This view describes these interfaces by which OpenSSO system's authority granting service functionality can be extended and customized Extension 1. This view can be extended to configure and implement authentication chaining. 2. This view can be extended to give more control to customized authentication modules for actual login, logout, abort or commit functions. 3. This view can be extended to dominate the user redirection end points after login success, failure or logout. 15

20 Architectural Views 3.2 Session Upgrade Transition View Viewpoint Specification Name Session Upgrade Transition Viewpoint Stakeholders All Concerns User session upgrade or downgrade facilities Modeled As Collaboration Viewpoint Source System Requirements Detail 16

21 Architectural Views Description This session upgrade process is the process in which already existing valid user session is enhanced with additional asserted data so that user can access multiple applications protected by different levels of authentication assertion statements, without need of re-authentication. The transitions of an existing valid session into an upgraded session are controlled by the Authentication Service based on the user actions to new authentication methods or the timedependent behaviors which are enforced by the Authentication Service. The Authentication Service triggers the creation of new session identifier and a new instance of a session object upon successful authentication. The Authentication Service should allow upgrading the session with new information within the same realm based on whether the user's request has a valid session or not. If a valid user session exists then the Authentication Service evaluates whether this user's session can be upgraded. The session upgrade is subject to successful authentication to the new authentication method requested. Upon authentication failure, the user's old session is returned to the user 17

22 Architectural Views without an upgrade. If the authentication is successful then the session is updated and enhanced with new properties based on the user's new authentication request Extension 1. This view does not describe certain use cases where a user's valid session can be upgraded across multiple authentication realms. 3.3 Authentication Client View Viewpoint Specification 18 Name Authentication Client Viewpoint Stakeholders Developers, Web Application Developers, System Integrators Concerns Remote Access to Authentication Service, Secure fire-wall friendly deployments Modeled As Collaboration, Web User Interface Viewpoint Source System Requirements

23 Architectural Views Detail Description This view illustrates the interactions between the Authentication Client and the Authentication Service when authentication requests are issued from the client end point. All requests associated with the same authentication context share the same and unique session identifier. Depending on 19

24 Architectural Views the actual deployment scenarios, the client web applications or client standalone applications can communicate with the Authentication Service through the Authentication Client libraries (also known as the Authentication SDK) via the public authentication interfaces or directly using authentication messaging interfaces which in turn invoke and complete the authentication process remotely by submitting the requests to the Authentication Service over the network transport layer. Also, in the Single Sign-On secure deployment environment, there is a need to be able to remotely access the Authentication Service for its presentation and credentials extraction capability in the DMZ in order to avoid two level penetration of fire-walls by web clients. The Distributed Authentication User Interface web application provides a remotable authentication presentation and extraction framework that can talk to the authentication server internally via Authentication client libraries, over the trusted connection for actual authentication. Normally SSO Agents deployed in the DMZ redirect user requests to the Distributed Authentication web application for completion of the authentication process by submitting required credentials in order to get valid user session and hence access to the agent protected resource in the SSO environment. Distributed Authentication web application deployments are required to be load balancer-friendly Extension 1. This view can be extended to include the scenario in which any Authentication Client can communicate to any Authentication Service on different OpenSSO systems. 3.4 Load Balancer Enabled Deployment View Viewpoint Specification 20 Name Load balancer friendly Deployment View Stakeholders Administrators, Web Application Administrator, System Integrators Concerns Internal Request Routing and Service Continuation, Security, Performance and Scalability, Protection against Denial Of Service attack Modeled As Deployment Viewpoint Source System Requirements

25 Architectural Views Detail 21

26 Architectural Views Description A cluster deployment of the Authentication Service is mandated when high system availability and service continuation need to be guaranteed. This view illustrates the mechanism used by the Authentication Service to process the authentication requests in the cluster environment. Since authentication requests may not always be distributed to the system where the respective session was originally created (or authentication process was started) the Authentication Service applies the request routing logic to forward the request to the correct or original SSO system based on the unique and self-contained session identifier Extension 1. This view can be further extended to address the requirements of infrastructure and enhanced authentication performance rate. 22

27 4 Authentication Service Conceptual Implementation In the OpenSSO project, the authentication interfaces and the resulting Authentication Service framework as a whole can be implemented with different approaches and using various methods. The end goals here are to address the overall system requirements as described in the OpenSSO system architecture and adhere to the viewpoint specifications as detailed within this Authentication Service architecture document. This chapter presents an overview of the conceptual implementation of the Authentication Service infrastructure with certain level of details on all the sub-components and services. 4.1 Authentication Service Software Implementation The main function of the Authentication Service infrastructure is to provide facilities for establishing basic user trust information (as authenticated user session) and relationship across a number of applications participating in the SSO environment. 23

28 24 Authentication Service Conceptual Implementation

29 Authentication Service Conceptual Implementation Authentication Service is based on JAAS framework for its Login API, Authentication modules SPI, credentials callbacks communication and Authentication configuration construction and usage part Authentication User Interface The Authentication User Interface is based on the Model-View-Controller architecture based user interface design framework, in order to facilitate the most dynamic and customizable user interface by clear separation of presentation layer from business logic processing part enabling that presentation. This interface provides a dynamic and customizable means for gathering authentication credentials requirements of all plugged in authentication modules at run time via single phase or multi-phase user interaction As J2EE web application This user interface is bundled and deployed as J2EE web application, the main components of which are Controller Servlet (LoginServlet), the only entry point for this web application JSP pages with display tags, which are rendered with as per conditional forwarding logic from associated ViewBeans. ViewBeans, which implement all the 'request handing' and logical processing in order to control the display by JSP pages. Model (Authentication API), which is nothing but the interaction of ViewBeans with the authentication API, authentication utilities and other configuration related services. Authentication modules credentials requirements (callbacks) XML files Functional Query Parameters support A URL parameter is a name/value pair appended to the end of a URL. The parameter starts with a question mark (?) and takes the form name=value. If more than one URL parameter exists, each parameter is separated by an ampersand (&). The following are some of the URL parameters that are supported to achieve various authentication functionalities. Realm / module / authlevel / user / role for invoking specific type (as per the query parameter name) of the authentication process. goto / gotoonfail for URL redirection on successful or failed authentication. Non-interactive login - Authentication can be done by passing the authentication information through a URL or web forms without going through the GUI interface. This process is called zero page login. Zero page login works only for the authentication modules requiring only 25

30 Authentication Service Conceptual Implementation single login page user interaction. The values of IDToken0, IDToken1,..., IDTokenN map to the authentication module callbacks used to provide the authentication information required by the authentication module. For example, the default LDAP authentication module uses IDToken1 for userid, and IDToken2 for password. So the login URL query parameters for the LDAP module look like: "module=ldap&idtoken1=userid&idtoken2=password". "module=ldap" can be omitted if LDAP is the default authentication module in this case Customization Directory level Authentication User Interface JSP pages can be customized per Realm, Locale, Client type or any Service of the SSO system, as per and following the required Directory lookup structure once created. By doing this, the User Interface becomes fully functional in different locals or in different client types like HTML, WML, CHTML, etc. JSP page level Each User Interface JSP page can be customized to have custom look and feel by altering display tags or UI elements to cater to different SSO system's branding Domain cookies management Authentication User Interface provides functionality of creating, setting and managing the domain cookies for session and Load balancers in order to enable the SSO for different applications accessing the same web clients where these cookies are set, in SSO environment Authentication API The Authentication Service provides the Application Programming Interface for any application, participating in the SSO environment and running locally or remotely to the authentication server, to access the authentication server, invoke or start an authentication process, submit credentials and get the SSO token (application or user). AuthContext Class Summary Create new AuthContext with realm name Create new AuthContext with realm name and the authentication server URL Create new AuthContext with realm name and user certificate nickname Create new AuthContext with existing valid session token Login to the already initiated Realm Login to the specific authentication type and its value 26

31 Authentication Service Conceptual Implementation AuthContext Class Summary Check for credentials requirements from authentication module Get credentials requirements of authentication module Submit user credentials against their requirements Get login exception Get error code Get error message Get error template Get login status Get Single-Sign-On token Get user's authenticated subject Get success redirect URL Get failure redirect URL Logout Abort Exception Summary AuthLoginException An AuthLoginException is thrown when there are errors during Authentication process using Authentication Client Interfaces. Table 1: Public Authentication API Distributed Authentication User Interface This User Interface is the remotable extraction, presentation and submission of credentials requirements for user from the authentication server via remote / client authentication interfaces over XML/HTTP(s). This User Interface is bundled and deployed as a J2EE web application (same as 4.1.1) except for the inclusion of authentication modules credentials requirements (callbacks) XML files. This web application is normally deployed in the DMZ talking remotely to the authentication server; hence, no secure data that defines the authentication requirement or processing part that evaluates or validates the authentication credentials, can reside in the Distributed Authentication Web Application. 27

32 Authentication Service Conceptual Implementation Other parts of the internal architecture, supported features and the customization design/support remain the same as Authentication Service Middle tier The Authentication Service Middle tier is based on the Java Authentication and Authorization Service (JAAS) framework. JAAS is designed to provide a secure authentication callbacks driven framework, standard programming interfaces and service provider interfaces for pluggable authentication modules. The Authentication Service Middle tier provides a layer above JAAS to support generic OpenSSO authentication features such as: Different authentication types User can authenticate to different authentication modules (single or chain of multiple authentication modules) configured for different realms, roles, users or services of the OpenSSO system Redirection URLs Evaluates the success or failure redirection URLs from different entry points such as a URL query parameter ( goto / gotoonfail ), configuration at realm / user / role / service level for these URLs. The URLs given as query parameters ( goto / gotoonfail ) takes highest priority here Account Lockout This Middle tier provides functionality of restricting the invalid credentials attempts by user in order to secure the OpenSSO system from malicious intrusion. It enables a feature where a user's account is locked out after "n" authentication failures. A user gets warned before an impending lockout after which the account gets locked. An notification is sent to the address configured as the lockout notification attribute. This feature can be turned on or off by OpenSSO system administrator. The following three types of account locking are supported: Physical locking Here the user's account gets locked by changing the value of the lockout attribute name with the lockout attribute value specified in OpenSSO user data store. These attributes can be configured by the OpenSSO system administrator. Memory Locking This can be enabled by changing the lockout duration to a value greater then 28

33 Authentication Service Conceptual Implementation 0. The user's account is locked in memory for the duration specified in the lockout duration attribute after which the account is unlocked. If the authentication server is restarted then all the accounts locked in memory are unlocked. Persistent Locking This feature can be enabled specially by the OpenSSO administrator in order to have a load balancer friendly environment across multiple authentication servers for invalid intrusions in the OpenSSO system. Here, users's invalid password attempts, last invalid attempt time and the time at which the user is locked out, all are stored persistently in the OpenSSO user data store Maintain user's login state The user's login state information is maintained from the time the user requests authentication until the time the user either logs out of OpenSSO system or the user's session is destroyed by any privileged application of the OpenSSO system. The user's login state information consists of: 1. Session Identifier Session Identifier created / associated with a user. 2. AuthContextLocal Local AuthContext object associated with a user. 3. Subject Users's authenticated credentials holder object. 4. IndexType Type of authentication used. 5. Index Name Value for Type of authentication used. 6. Realm Name Realm of the OpenSSO system in which user is authenticating. 7. LoginStatus Status of the authentication (IN_PROGRESS/COMPLETED/SUCCESS/FAILED/NOT_STARTED/ERROR). 8. Received Callbacks Callbacks required / received from authentication module. 9. Submitted Callbacks Callbacks submitted by user against the credentials requirements of authentication module. 10. Locale Locale of the authenticating user request 11. Success / Failure redirect URLs URLs to be redirected to, after success or failure authentication Generation of User session A user's session is created from the beginning of the authentication process and then validates after successful authentication or destroyed after failure authentication or session destroy event generation. After successful authentication, the following properties are set in user's authenticated valid 29

34 Authentication Service Conceptual Implementation session: 1. realm name 2. user identifier 3. role of the user 4. UUID (universal unique identifier) 5. authentication module/s used for authentication 6. authentication level configured for the authentication module/s used 7. name of the authentication modules chain used 8. type of authentication used 9. value for type of authentication used 10. client IP address 11. client type of user request 12. locale of user request 13. character set of user's web request 14. user's success redirect URL 15. user's failure redirect URL 16. user's authenticated principals 17. session idle time-out period 18. session maximum cache time-out period 19. maximum valid session time-out period Session Upgrade The Authentication Service Middle tier allows upgrading the user's session with new information within the same realm based on whether the user's request has a valid session identifier or not. If a valid user session exists then this logical tier evaluates whether a user's session can be upgraded. The session upgrade is subject to successful authentication to the new authentication type requested. If the authentication fails then the user's old session is returned to the user without an upgrade. If the authentication is successful then the session is updated with new properties based on the user's authentication request for new authentication type. The following session properties are upgraded or updated after successful session upgrade for a user: 1. Authentication level to the highest authentication level used from old and new type of authentication 30

35 Authentication Service Conceptual Implementation 2. Authentication modules chain name to the union of chain names from old and new type of authentication 3. User's role to the union of user roles from old and new type of authentication 4. Authentication module to the union of authentication modules from old and new type of authentication Important Objects Class Summary AuthD This class is used to initialize the Authentication service and retrieve the Global attributes for the Authentication service. It also initializes the other dependent services in the OpenSSO system and hence used as bootstrap class for the authentication server. AuthUtils This class has utility methods for domain cookie management, URL formatting, getting handle to AuthContext and LoginState objects, retrieving and validation session from session identifier, retrieving the client types attribute fields that determines the client type, etc. AMLoginContext This class is the core layer in the Authentication middle tier which connects user clients to the JAAS LoginModule. The AMLoginContext executes pre and post authentication processes based on authentication status. AMLoginContext provides a synchronous layer on top of the JAAS framework for appropriate user interaction and communication between clients and authentication module via callbacks requirements. AMLoginContext sets and retrieves the Authentication configuration entry. This class actually starts the JAAS login process by instantiating the LoginContext object with the JAAS Configuration name and the CallbackHandler followed by calling the LoginContext::login() method. LoginState This class maintains the User's login state information from the time user requests for authentication till the time the user either logs out of the OpenSSO system or the session is destroyed by any privileged application of the OpenSSO 31

36 Authentication Service Conceptual Implementation Class Summary system. DSAMECallbackHandler This class implements the JAAS CallbackHandler Interface for passing authentication credentials requirements data or display warning messages via JAAS Callbacks or custom Callbacks. It provides handle(callback[] callbacks) method for the JAAS LoginModule to pass the credentials callbacks to be sent to the user client. AMAccountLockout This class provides methods to retrieve and set the Account lockout related information for the user and also facilitates the methods to enforce the user account lockout. Exception Summary AuthException An AuthException is thrown when there are errors related to framework classes execution. Table 2: Authentication Framework Interfaces Authentication SPI The following are the public Service Provider Interfaces, which facilitates the extension of the Authentication Server functionality by adding and executing the hook of the respective implementation of these SPIs. AMLoginModule Interface Summary (Interface to write and plug-in custom authentication module) Abstract method, to be implemented by every authentication module to initialize and retrieve the module configuration information Abstract method, to be implemented by every authentication module to control the flow of callbacks communication as per module specific callbacks requirements for User interaction and submission of required user credentials Abstract method, to be implemented by every authentication module to retrieve the authenticated user principal 32

37 Authentication Service Conceptual Implementation AMPostAuthProcessInterface Interface Summary (Interface to invoke custom implementation after authentication process but before exit from Authentication service) Method which gets access after successful authentication, to execute custom implementation Method which gets access after failure authentication, to execute custom implementation Method which gets access after logout operation, to execute custom implementation UserIDGenerator Interface Summary (Interface to generate unique user identifiers in OpenSSO user data store during self registration process) Method to generate unique user identifiers as per the customized logic for self user registration process AMAuthCallBack Interface Summary (Interface to be implemented by external business logic code, in order to receive callbacks from the authentication framework upon user account lockout event or user password change event) Initialize and retrieve the module configuration Retrieve module's credentials requirements in the form of callbacks Method to receive the event notifications when the user status changes during the authentication process. It includes the type of event and other information pertinent to this event in the form of Map Exception Summary AuthenticationException An AuthenticationException is thrown when there are errors during execution of custom business logic implementation of AMPostAuthProcessInterface Interface AMAuthCallBackException An AMAuthCallBackException is thrown on erroneous conditions and when required by custom business logic implementation of AMAuthCallBack Interface Table 3: Public Authentication SPI 33

38 Authentication Service Conceptual Implementation Authentication Modules The following authentication modules validating user credentials against their respective data stores and having credentials callbacks information as per the requirement of these respective data stores are supported out-of-the-box: 1. LDAP An authentication module authenticating and validating user credentials against Sun Java System Directory Server or any other LDAPV3 compliant Directory server. It enables authentication using LDAP bind, a Directory Server operation that associates a user ID and a password with a particular LDAP entry. It additionally supports all the Password controls delivered by the Sun Java System Directory server such as Password expiration, Password reset, etc. It also provides high availability against Directory server downtime by facilitating the failover (from a primary DS to a secondary DS) and failback (from a secondary back to a primary DS) support. 2. Membership An authentication module authenticating and validating user credentials against Sun Java System Directory Server or any other LDAPV3 compliant Directory server (same as LDAP), in addition to providing a user registration (self-registration) process implementation and flow, in OpenSSO user data store. This module is implemented for personalized sites. When membership authentication is enabled, a user can self-register. This means that the user can create an account, personalize it, and access it as a registered user without the help of an administrator. 3. Certificate An authentication module that enables a user to log in through a personal digital certificate (PDC). The module instance can require the use of the Online Certificate Status Protocol (OCSP) to determine the state of a certificate. Use of the OCSP is optional. The user is granted or denied access to a resource based on whether or not the certificate is valid. 4. JDBC The Java Database Connectivity (JDBC) authentication module allows Access Manager to authenticate users through any Structured Query Language (SQL) databases that provide JDBC-enabled drivers. The connection to the SQL database can be either directly through a JDBC driver or through a JNDI connection pool. 5. Active Directory This module works similarly to the LDAP authentication module, but authenticates against the Microsoft Active Directory. Using this module makes it possible to have both LDAP and Active Directory coexist in the same realm in the OpenSSO system. 34

39 Authentication Service Conceptual Implementation 6. MSISDN The Mobile Station Integrated Services Digital Network (MSISDN) authentication module enables authentication using a mobile subscriber ISDN associated with a device such as a cellular telephone. It is a non-interactive module. The module retrieves the subscriber ISDN and validates it against the Directory Server to find a user that matches the number. 7. Anonymous This module allows a user to log in without specifying credentials. You can create an Anonymous user so that anyone can log in as Anonymous without having to provide a password. Anonymous connections are usually customized by the OpenSSO system administrator so that Anonymous users have limited access to the OpenSSO server system. 8. WindowsDesktopSSO This module is specific to Windows and is also known as the Kerberos authentication module. The user presents a Kerberos token to the OpenSSO authentication service through the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol. The Windows Desktop SSO authentication plug-in module provides a client (user) with desktop single signon. This means that a user who has already authenticated with a key distribution center can be authenticated with OpenSSO system without having to provide the login information again. 9. WindowsNT The Windows NT Authentication module allows for authentication against a Microsoft Windows NT server. 10. HttpBasic The HttpBasic authentication module allows authentication using the HTTP basic authentication with no data encryption. A user name and password are requested through the use of a web browser. Credentials are validated internally using configured backend authentication data store. 11. Unix This Solaris-only module allows for authentication using a user's UNIX identification and password Authentication Configuration The Authentication Configuration Component consists of following items: Configuration Service schema A schema definition as per the configuration service schema 35

40 Authentication Service Conceptual Implementation of the OpenSSO system, in order to define the service configuration attributes for each authentication module service, create multiple instances of each authentication module and create chains of authentication module instances, under each realm of the OpenSSO system. JAAS Configuration Implementation Extension of JAAS Configuration that programmatically sets its own class as the JAAS configuration in the OpenSSO system. This extended class (JAAS Configuration Implementation) gets authentication module configurations for realms, roles, users and services. It also defines and retrieves the JAAS configuration entry for every authentication module as per JAAS semantics (e.g. Module name, control flag and options passed to the module). Authentication Configuration Utilities The API utilities for applications and other authentication components which need to retrieve Authentication configuration. Administration Provision of administrative interfaces (or direct configuration data store interfaces) in order to configure the authentication module instance or chain of authentication module instances to different realms, users, roles of users or services in the OpenSSO system, for more granular control of authentication process. Class Summary AMConfiguration This class extends and sets JAAS Configuration. It provides methods to create and retrieve Authentication Configuration entries per realm, user, role, service, authentication module or authentication level, including the base JAAS configuration entry for each authentication module (module name, control flag and options passed to the module) AMAuthConfigUtils This class provides configuration utility methods such as: A parsing utility for the value of the authentication configuration entry from XML to JAVA objects and vice versa An API utility to get the configuration entry name given authentication type and its value An API utility to get authentication modules given an authentication level An API utility to get plugged-in authentication module class name Table 4: Authentication Configuration Interfaces 4.2 Authentication State Structure User's login state information and structure heavily depends on following objects: 36

41 Authentication Service Conceptual Implementation Session Identifiers The session ID (or SSOToken ID) is an opaque handle that is a pointer to a newly created session. It is used to locate the session object. Every time a user requests the Authentication server, the session ID is retrieved from the user's request and used to retrieve the associated session object, which first passes the session validation test. AuthContextLocal The local AuthContextLocal object holds all the important authentication characteristics of the user, such as authentication type used, its value, etc. This object is stored in the session object and retrieved from it, for all continuing user authentication requests. Callbacks All the received Callbacks from the authentication module (as per its credentials requirements) and the user's submission against them, maintained for all multi-phase authentication requests. The following diagram shows, how a user's authentication or login state information is maintained from the time the user requests authentication (this could be single phase for multi-phase process) until the time the user either logs out of the OpenSSO system or the user's session is destroyed by any privileged application of the OpenSSO system. 37

42 38 Authentication Service Conceptual Implementation

43 Authentication Service Conceptual Implementation 4.3 Session Interface Point 39

44 Authentication Service Conceptual Implementation The Authentication Service interfaces and depends on the Session service in the OpenSSO system, for the following: Initiation or creation of user sessions Maintenance of its state information Activation of sessions after successful authentication Population of all user-authenticated properties into valid session Destruction of sessions after logout 4.4 Other Services Interface Point 40

45 Authentication Service Conceptual Implementation In the OpenSSO system, the Authentication Service interfaces with other services such as: Configuration Service This service provides the data store agnostic abstraction layer on top of the configuration data store for other functional Services of the OpenSSO system to access and manage configurations in the configuration data store. The Authentication Service interacts with this service for its configuration data management such as creation / modification / retrieval and deletion of authentication modules, chains of modules, and association of authentication chains to realm or user or service or role. 41

46 Authentication Service Conceptual Implementation User Data Repository Management Service The Authentication Service interacts with this service in order to retrieve user profile information when required by the OpenSSO system, to manage user account lockout information such as the configured number of authentication failure attempts before enforcing account lockout or to create new user via self-registration process. Naming Service The Authentication Service interacts with this service to lookup and validate the Authentication server's (OpenSSO system) existence and availability in the cluster environment. Logging Service Authentication service interacts with logging service for authentication events logging audit reports generation. Normally following events are logged by Authentication service with information of the user identifier and the log message id associated with the appropriate log event message: Login success Login failure Logout Monitoring Service Authentication service interacts with monitoring service to provide the facility to monitor the authentication related resource consumption. 4.5 SSO Agent Interface Point All SSO Agents protecting system resources in OpenSSO system, interacts with Authentication Service in two ways: 42 for Agent authentication itself in order to establish trust against themselves with OpenSSO system. This authentication normally happens via authentication client interfaces. for User authentication, when non trusted user or user having no valid session tries to access the protected resource. This authentication normally happens as client browser redirect authentication to Distributed Authentication server.

47 Authentication Service Conceptual Implementation 4.6 Internal Request Routing Scheme The Authentication process is a single phase or multi-phase process (for single module or chain of modules) in which the user accesses the Authentication Server in a sequential manner for multiple 43

48 Authentication Service Conceptual Implementation sets of credentials callbacks submission. In order to successfully complete this authentication process, authentication state information such as the type of authentication invoked and the callbacks prompted / submitted by the user, needs to be maintained and all the subsequent user authentication requests in a multi-phase authentication process, need to be submitted against this state. The Authentication Service introduces and implements a basic request routing scheme to route the user authentication request during multi-phase authentication process to the original authentication server, that originally created a session, and which maintains authentication state information, in cluster deployment behind a Load Balancer. 44

49 Authentication Service Conceptual Implementation First, with the request routing scheme, each session is assigned a primary server instance and a 45