If you simply run this program, you can expect an IOException when you try and
access the input stream. This will be the 401 HTTP error code indicating that you are
not authorized. We are going to get around this by making the client supply a token,
and then configuring an Identity Assertion Provider to accept this token and authorize
the user. Identity Assertion Providers can automatically take advantage of
request cookies or headers. If WebLogic finds, for example, a header property with
the same name as a token (we will see in a moment how to configure the identity
provider with token names), it assumes that the content of the header property is the
value of the token. The token we will use is a simple string that we are going to send
in the HTTP request header when we create the connection to the server. To this
end, modify the preceding code to read as follows:

The name of the request property, MyToken in our example, is significant. This is
interpreted as the type of the token, which we will see later. A small caveat here is
that WebLogic always expects incoming tokens to be Base 64-encoded. You can do
this by using the utility class weblogic.utils.encoders.BASE64Encoder. So, to create
an encoded token, you can write something such as this:

The text that you place in the token can be anything you please, as long as your Identity
Assertion Provider can read it. In our example, we will use a simple string, which
we take to represent the authenticated user.

Note: WebLogic 8.1 allows you to configure the Identity Assertion Provider
to use tokens that aren't encoded, in which case you won't need to use
an encoder.

All that's left now is to create an Identity Assertion Provider. The MBean definition
file used in our example is given in Example 17-8 in full.

The most important methods are initialize( ) and assertIdentity( ). The
initialize() method simply extracts some information from the MBean representing
the provider and uses it to create the description. The assertIdentity( ) method
is given two parameters, the type of the token and the token itself. We simply check
that the token type is correct and map the token to the username. You could conceivably
do a lot more here, such as validate the authenticity of the token for stronger
security. The method must return a standard JAAS callback handler, which
eventually will be invoked to extract the username (that is, only the NameCallback will
be used). We use the callback handler that we defined in Example 17-4. Note that
the identity asserter could have been an authenticator too, in which case it could
populate the subject with usernames and groups belonging to the user. Because we
are doing pure identity assertion, the corresponding methods simply return null.

Place this file and the callback handler in the out directory, and then issue the following
command to create a packaged provider:

Copy this to the WL_HOME/server/lib/mbeantypes directory, and then reboot the
server. Start up the Administration Console and navigate to the Security/myrealm
Providers/Authentication node. In the list of available authenticators and identity
asserters, you should find an option for "Configure a new MyA...". Selecting this
option and clicking Create will configure the identity asserter. On the following tab
you will notice that the support token type is set to MyToken and the active token to
MyToken too. You will now have to reboot the server for this change to take effect.

If you rerun the client application, you will find that you will no longer get an unauthorized
warning (assuming that jon is in the permission group mysecrole, which was
granted access to the web resource). To further illustrate the point, you can try
accessing a servlet or JSP page in this way, which has a call to request.
getUserPrincipal( ). You will find that this call returns jon as you would expect.

So, here is a summary of what happens, as was illustrated in Figure 17-2:

The client attempts to access a protected web page. The web container notes
that the client does not have any security credentials and that the web application
implements identity assertion, so it fires up the Identity Assertion Providers,
passing in the appropriate request parameters.

The Identity Asserter grabs the username directly from the incoming token and
returns it in the form of a callback handler.

Any login modules that you have configured for the security realm then fire,
using the callback handler to fetch the username. So, for example, the Default
Authenticator will fire and log in the user. However, because it knows that the
data comes from the Identity Asserter, it will not require a password. As a result,
the user is logged in and can now access the web application.

Avinash Chugh, Jon Mountjoy
presently works as Senior Development Manager for a firm that produces software for the regulated industries (finance, energy, pharmaceutics).