About Authentication Security Providers in Oracle WebLogic

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

o                  A special type of Authentication provider that handles perimeter-based authentication

·                     Principal Validation Providers

o                  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

o                  It could be a LDAP server, a SQL database, or other data store.

·                     Simple authentication vs Perimeter-based authentication^[1,11]

o                  Simple authentication

§                WebLogic Server establishes trust itself through usernames and passwords

o                  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

o                  A user can be a person or a software entity, such as a Java client. 

o                  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. 

o                  When a user attempts to access a particular WebLogic resource, WebLogic Server tries toauthenticate 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

o                  Groups are logically ordered sets of users. Usually, group members have something in common.

o                  Managing groups is more efficient than managing large numbers of users individually.

·                     Security Realm

o                  A container for the mechanisms—including users, groups, security roles, security policies, andsecurity providers—that are used to protect WebLogic resources.

·                     Principal

o                  A principal is an identity assigned to a user or group as a result of authentication. Both usersand groups can be used as principals by application servers. 

·                     Subject

o                  The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals. 

o                  Figure 1 illustrates the relationships between users, groups, principals, and subjects.

·                     Authentication Service/Provider

o                  An Authentication provider allows WebLogic Server to establish trust by validating a user. 

o                  You must have one Authentication provider in a security realm, and you can configure multiple Authentication providers in a security realm.

o                  Authentication service in WebLogic Server is implemented using the JAAS standard.^[3]

o                  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

o                  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 makingauthorization decision.^[10]

·                     Identity Assertion Service/Provider

o                  An Identity Assertion provider is a special type of Authentication provider that handlesperimeter-based authentication and multiple security token types/protocols.

o                  An Identity Assertion provider verifies the tokens and performs whatever actions are necessary to establish validity and trust in the token. 

o                  Identity Assertion providers support the mapping of a valid token to a user.

o                  Each Identity Assertion provider is designed to support one or more token formats.

·                     LoginModule

o                  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 thesecurity 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 provideralso 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 theprincipals (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 ofperimeter-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 thePassword Validation provider to ensure that the password meets the composition requirements that are established.

Performance Turning for WebLogic Server

Performance Turning for WebLogic Server - Native Muxers vs. Java Muxers

There are two critical areas for WebLogic Server (WLS) performance tuning:

·                     Thread management

·                     Network I/O tuning

In this article, we will touch upon one aspect of Network I/O tuning—Native Muxers vs. Java Muxers.

Listen Thread

  Listen Thread ---> Listen Thread Queue --> Socket Muxer 

When a server process starts up, it binds itself to a port and assigns a listen thread to the port to listen for incoming requests.  Once the request makes a connection, the server passes the control of that connection to the socket muxer.

From the thread dump, you can find an entry like this:

  "DynamicListenThread[Default[9]]" daemon prio=10 tid=0x00002aaac921b800 

   nid=0x3bf1 runnable [0x000000004c026000]

From the server log file, you can find a matching entry like this:

  <Oct 2, 2012 11:02:28 AM PDT> <Notice> <Server> <BEA-002613>

  <Channel "Default[9]" is now listening on 0:0:0:0:0:0:0:1:9000 

  for protocols iiop, t3, ldap, snmp, http.>

Socket Muxer

  socket muxer --> execute queue  

Muxers read messages from the network, bundle them into a package of work, and queue them to the Work Manager.  An idle execute thread will pick up a request from the execute queue and may in turn hand off the job of responding to those requests to special threads.  Finally, socket muxers also make sure the response gets back to the same socket from which the request came. Socket muxers are software modules and there are two types: 

·                     Java Muxers

o                  Uses pure Java to read data from sockets

o                  The number of threads is tunable for Java muxers by configuring the Percent Socket Readers parameter setting in the Administration Console

·                     Native Muxers 

o                  Native muxers use platform-specific native binaries to read data from sockets

§                The majority of all platforms provide some mechanism to poll a socket for data

o                  Native muxers provide better performance, especially when scaling to large user bases, because they implement a non-blocking thread model

The Enable Native IO checkbox on the server’s configuration settings tells the server which version to use.  In the above figure, we have selected Native IO and, therefore, JavaSocketMuxer Socket Readers was grayed out.

In general, the server will determine the correct type of muxer to use and will use the native muxers by default without having to make any specific tuning changes. 

Which Muxer Was Actually Used?

The quickest way is to create a thread dump (for example, using jstack) and search for "Muxer".  In our experimental environment, Posix Muxer was picked up accidentally:

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00002aaae190b800 nid=0x10cf runnable [0x0000000040e13000]
   java.lang.Thread.State: RUNNABLE
        at weblogic.socket.PosixSocketMuxer.poll(Native Method)
        at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java

-Dweblogic.SocketReaders

You can explicitly set the number of socket readers using the following command line option:

·                     -Dweblogic.SocketReaders=3

If you set it to be 3, you can find the following entries from the thread dump:

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00002aaac8776000 nid=0x3475 waiting for monitor entry [0x0000000041dbd000]

   java.lang.Thread.State: BLOCKED (on object monitor)

"ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00002aaac8774800 nid=0x3474 waiting for monitor entry [0x0000000041cbc000]

   java.lang.Thread.State: BLOCKED (on object monitor)

"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00002aaac8770000 nid=0x3473 runnable [0x0000000041877000]

   java.lang.Thread.State: RUNNABLE

The main reason to do this is that in some releases the number of readers is set by default to the number of CPUs available on the system. On some types of hardware this results in as many as 128 reader threads, which is not so good.

Typically you will see good performance anywhere between 1-3 socket readers threads. In some case, folks have used 6—but, those are special cases.  Be warned that not having enough readers will result in work not being read from the sockets quickly enough for the server to process.

Using our ATG CRM benchmark, you can see the changes of throughput and response time when number of SocketReaders is changed from 1 to 3:

	SocketReaders=1	SocketReaders=3
Maximum Running Vusers	400	400
Total Throughput (bytes)	2,487,087,264	2,496,307,995
Average Throughput (bytes/second)	1,036,286	1,040,128
Average Hits per Second	29.786	29.86
Average Response Time (seconds)	0.248	0.236
90% Response Time (seconds)	0.209	0.210

BEA-000438

In some circumstances, you may see the following error message:

  <BEA-000438> <Unable to load performance pack. Using Java I/O instead.

  Please ensure that libmuxer library is in...

For instance, when you use 64-bit JVM and libmuxer.so is not on the LD_LIBRARY_PATH.  To resolve it, just add the following path:

·                     <Oracle Home>/wlserver_10.3/server/native/linux/x86_64

to the LD_LIBRARY_PATH. 

Acknowledgement

Some of the writings here are based on the feedback from Sandeep Mahajan. However, the author would assume the full responsibility for the content himself.