The Default Authenticator
The Default Authenticator authenticates against the embedded LDAP repository. It provides the notion of a user and group and stores user and group information in its own repository, allowing you to manipulate this information. The only configurable option provided by this Authenticator is the Minimum Password Length setting. By default, all WebLogic users must specify a password that is at least eight characters in length; the password length is validated when the user is created. When you log on to the Administration Server using the console or through a JNDI context, it is generally this authenticator that validates the username and passwords you supply. Of course, the control flag will determine exactly which providers are called.
Configuring an LDAP authenticator
WebLogic also lets you configure an Authentication Provider that can use existing external LDAP directories such as iPlanet LDAP, Active Directory, Open LDAP, and Novell NDS. In fact, WebLogic's LDAP Authenticators can interface with any LDAP v3-compliant directory servers. In this section, we look at how you can set up an iPlanet Authenticator for your security realm. Other LDAP Authenticators can be configured along the same lines. By using one of the LDAP Authenticators, you can configure WebLogic to recognize users and groups defined in the LDAP repositories and authenticate against this information.
First, select the Authentication node under the realm from the left frame of the
Administration Console. If you're using the default security realm
myrealm, then the
node will be under Security/Realms/myrealm/Providers. Then, select the "Configure a
new iPlanet Authenticator" option, either by right-clicking the node or from the right
frame itself. Now under the General tab on the right, you'll see the overall details of
the new Authenticator. Choose a name for the Authenticator and make sure that the
value of the JAAS Control Flag is Required, and then hit the Create button.
Note: When starting out, it may be useful to set the Control Flag to Optional. In this way, even if your LDAP authentication fails, you still can authenticate using WebLogic's default authenticator and gain access to the Administration Console.
Now select the iPlanet LDAP tab, and enter the values for the host, port, and principal
as they apply to your LDAP server. Here, the principal refers to the distinguished
name (DN) of the LDAP user that WebLogic will use to connect to the LDAP Server.
Typically, you'll use the DN associated with some administrative user account on the
LDAP server. For iPlanet LDAP, this is usually
o=NetscapeRoot. If the LDAP server is listening on an SSL
port, tick the SSL Enabled option and ensure that you've specified the SSL port. Now
hit the Apply button to save changes to the form. Next, change the Credential
attribute for the LDAP Principal. In the new screen, you must enter the password
that will be used to authenticate the LDAP user defined in the Principal attribute.
Now, select the Users tab and make sure the fields in this form match the configuration
of your LDAP repository. In most cases, you will need to modify only the value
of the User Base DN attribute to
o=mydomain.com. This attribute defines
the base DN of the branch within the LDAP tree that holds the actual users.
Table 17-3 lists the other configuration settings under the Users tab.
Table 17-3. Configuring the Users tab for an LDAP Authenticator
|User Object Class||This attribute indicates the LDAP object class that holds user information|
|User Name Attribute||This setting specifies the name of the attribute within the LDAP user object that holds the username.|
|User Search Scope||This setting determines how the users are organized in a multilevel hierarchy or a flat, single-level tree. It affects how deep in the hierarchy to search for users. You can choose from the following values: subtree/onelevel.|
|User From Name Filter||This attribute specifies a search filter for finding a user given the username.|
WebLogic populates these fields with sensible default values, so in most cases you
won't have to alter them. Hit the Apply button and move on to the Groups tab.
Again, you need to ensure the settings accurately reflect the structure of your LDAP
repository. In most cases, you will need to modify only the Group Base DN setting to
o=mydomain.com. Table 17-4 lists the other configuration settings
available under the Groups tab.
Table 17-4. Configuring the Groups tab for an LDAP Authenticator
|Static Group Object Class|
|Static Group Name Attribute|
|cn Group Search Scope|
|Group From Name Filter|
These settings are pretty straightforward, and they have the same semantics as the attributes under the Users tab, just applied to groups.
The Membership tab determines how group members are stored and located in the LDAP directory. WebLogic specifies default values for all fields in the form. Table 17-5 lists two important attributes under the Membership tab.
Table 17-5. Configuring the Membership tab for an LDAP Authenticator
|Static Member DN Attribute||This setting specifies the name of the attribute within the LDAP group object that holds the DNs of members of the group.|
|Static Group DNs from Member DN Filter||This attribute specifies a search filter for finding all groups that contain the member, given the name of the group member.|
Unlike the other authentication providers, the iPlanet provider also supports dynamic groups for which there are additional options.
Now that you have configured the LDAP Authenticator, you are almost ready to reboot the Administration Server. However, you need to ensure that the server's boot identity (i.e., the WebLogic user account used to start the server) corresponds to an LDAP user with the necessary Admin privileges. This means you need to use the iPlanet Console (or any management tool specific to the LDAP server) and complete the following steps:
Create an Administrators group in the LDAP repository and place the LDAP user, which is associated with WebLogic's boot identity, in this group.
If you are unable to create an Administrators group, create a new group in the LDAP Repository—say, MyAdministrators. Make the LDAP user, which is associated with WebLogic's boot identity, a member of the MyAdministrators group. Then using WebLogic's Administration Console, assign the MyAdministrators group to the default global role Admin.
By doing this, you guarantee that WebLogic's boot identity has the required Admin privileges. The next time you restart the server, go into the Administration Console and remove the Default Authenticator from the list of Authentication Providers. Once you've applied these changes, restart the server—hopefully, you should be able to boot without any authentication errors and set up your WebLogic domain to use the LDAP repository for its user and group information base.
The Default Identity Asserter
The Default Identity Asserter supports perimeter authentication using either X.509
certificates or IIOP CORBA Common Secure Interoperability Version 2 (CSIv2)
tokens. A good example of perimeter authentication is when you configure a web
application to use
CLIENT-CERT authentication. In this case, WebLogic can perform
identity assertion based on values from request headers and cookies. If the header
name or cookie name matches the active token type for the provider, the value is
passed to the provider.
This provider requires you to configure the following attributes:
- User Name Mapper Class Name
- This attribute specifies the name of a Java class that maps the X.509 certificates or
X.501 DNS to WebLogic users, according to some scheme. The User Name Mapping
class must implement the
weblogic.security.providers.authentication. UserNameMapperinterface, and also must be available in WebLogic's
- Trusted Client Principals
- This attribute specifies a list of client principals that may rely on CSIv2 identity assertion. You can use the wildcard character (*) to indicate that all client principals are trusted. If a client principal isn't included in this list, the CSIv2 identity assertion fails and access is denied.
Note that Identity Assertion Providers do not verify proof material. A user can forge a CSIv2 token, for instance, and assume a false identity. Because WebLogic cannot trust such tokens, the Trusted Client Principals setting offers a way to restrict the set of client principals that can use identity assertion. We saw a good example of using X.509 certificates as perimeter authentication in the previous chapter, where we also supplied a custom username mapper class for mapping digital certificates to WebLogic users. When using two-way SSL and X.509 certificates for identity assertion, the SSL protocol ensures that the certificate is not forged. So, the Trusted Client Principals setting applies only to CSIv2 identity tokens.
WebLogic 8.1 comes with a default username mapper that you can enable from the Details tab. This is a general username mapper that can be configured to extract a username from a given attribute of the subject DN field in a certificate. So, for example, if the client's certificate has an email attribute (E), then you can set the Default User Name Mapper Attribute Type to E. You also can specify a delimiter, in which case WebLogic will use that part of the attribute up to but not including the delimiter. For instance, if you need to extract a username from the email attribute, you will want to use the delimiter @. Other attribute types that can be used are the C, CN, L, O, OU, S, and ST types. If you need anything more complex than this, you will have to create your own username mapper class. See Example 17-2 later in this chapter to learn how you can write a custom username mapper.