Wednesday, January 8, 2014

Understanding Authentication Security Providers in Oracle WebLogic

There are three main types of security providers in WebLogic Server that are involved in the authentication flow:
  • Authentication Providers
  • Identity Assertion Providers
    • A special type of Authentication provider that handles perimeter-based authentication
  • Principal Validation Providers
    • Primarily acts as a "helper" to an Authentication Provider to provide an additional protection of the Principal in a Subject
You can also configure a Realm Adapter Authentication provider that allows you to work with users and groups from previous releases of WebLogic Server.  In this article, we group them as authentication security providers.

Authentication Security Providers


WebLogic Server includes numerous authentication security providers.  Most of them work in similar fashion: given a username and password credential pair, the provider attempts to find a corresponding user in the provider's data store. These Authentication security providers differ primarily in:
  • What data store is used
    • It could be a LDAP server, a SQL database, or other data store.
  • Simple authentication vs Perimeter-based authentication[1,11]
    • Simple authentication
      • WebLogic Server establishes trust itself through usernames and passwords
    • Perimeter-based authentication
      • In perimeter authentication, a system outside of WebLogic Server establishes trust through tokens (note that a token will be usually passed through the request headers).
      • If you are using perimeter-based authentication, you need to use an Identity Assertion provider

Terminology

Before we start, let's cover some basic security concepts:
  • User
    • A user can be a person or a software entity, such as a Java client. 
    • A user with a unique identity must be defined in a security realm[6] in order to access any WebLogic resources belonging to that realm. 
    • When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular WebLogic resource.  Note that we only focus on the authentication process in this article.
  • Group
    • Groups are logically ordered sets of users. Usually, group members have something in common.
    • Managing groups is more efficient than managing large numbers of users individually.
  • Security Realm
    • A container for the mechanisms—including users, groups, security roles, security policies, and security providers—that are used to protect WebLogic resources.
  • Principal
    • A principal is an identity assigned to a user or group as a result of authentication. Both users and groups can be used as principals by application servers. 
  • Subject
    • The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals
    • Figure 1 illustrates the relationships between users, groups, principals, and subjects.
  • Authentication Service/Provider
    • An Authentication provider allows WebLogic Server to establish trust by validating a user. 
    • You must have one Authentication provider in a security realm, and you can configure multiple Authentication providers in a security realm.
    • Authentication service in WebLogic Server is implemented using the JAAS standard.[3]
    • JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. 
  • Principal Validation Service/Provider
      • Primarily acts as a "helper" to an Authentication Provider to provide an additional protection of the Principal in a Subject by:
        • Signing the Principal populated by the LoginModule
        • Verifying the Principal retained in the client application code when making authorization decision.[10]
    • Identity Assertion Service/Provider
      • An Identity Assertion provider is a special type of Authentication provider that handles perimeter-based authentication and multiple security token types/protocols.
      • An Identity Assertion provider verifies the tokens and performs whatever actions are necessary to establish validity and trust in the token. 
      • Identity Assertion providers support the mapping of a valid token to a user.
      • Each Identity Assertion provider is designed to support one or more token formats.
    • LoginModule
      • A LoginModule is a required component of an Authentication provider.  It is the work-horses of authentication: all LoginModules are responsible for authenticating users within the security realm and for populating a subject with the necessary principals (users/groups). 



    Username/Password Authentication Process


    Authentication is the process of verifying an identity claimed by or for a user or system process. An authentication process consists of two steps:
    1. Identification—presenting an identifier to the security system.
    2. Verification—presenting or generating authentication information that corroborates the binding between the entity and the identifier.
    Authentication answers the question, Who are you? using credentials such as username and password combinations. An Authentication provider is used to prove the identity of users or system processes. The Authentication provider also stores, transports, and makes identity information available to various components of a system when needed. During the authentication process, a Principal Validation provider supports additional security protections for the principals (users and groups) contained within the subject, by first signing and later verifying the authenticity of those principals for each use.

    In Figure 2, we show you the basic authentication flow of simple authentication.  For the authentication flow of perimeter-based authentication, you can read [4] for details.

    When a user attempts to log into a system using a username/password combination, WebLogic Server establishes trust by validating that user's username and password, and returns a subject that is populated with principals per JAAS requirements.[3] As Figure 2 also shows, this process requires the use of a LoginModule and a Principal Validation provider.

    You can configure multiple authentication security providers in a security realm.  You can also configure the JAAS Control Flag for each Authentication provider to control how it is used in a login sequence.  Read [7] for more details.

    Finally, Oracle recommends that you also configure the Password Validation provider,[8,9] which works with several out-of-the-box authentication providers to manage and enforce password composition rules. Whenever a password is created or updated in the security realm, the corresponding authentication provider automatically invokes the Password Validation provider to ensure that the password meets the composition requirements that are established.

    References

    1. Configuring Authentication Providers—Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.4)
    2. Principal Validation (Introduction to WebLogic Enterprise Security)
    3. JAAS Reference Guide
    4. Introduction to WebLogic Enterprise Security
    5. Oracle® Fusion Middleware Developing Security Providers for Oracle WebLogic Server 11g Release 1 (10.3.5)
    6. Security Realms
    7. Java Authentication and Authorization Service (JAAS)
    8. System Password Validation Provider: Provider Specific
    9. Password Composition Rules for the Password Validation Provider
    10. The Authorization Process
    11. The WebLogic Server security architecture supports:
      • Password-based and certificate-based authentication directly with WebLogic Server; HTTP certificate-based authentication proxied through an external Web server; perimeter-based authentication (Web server, firewall, VPN); and authentication based on multiple security token types and protocols.
    12. Understanding Login Authentication

    No comments: