ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Java and Security, Part 2
Pages: 1, 2, 3, 4, 5, 6, 7, 8

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 uid=admin, ou=Administrators, ou=TopologyManagement, 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 ou=people, 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

SettingDescriptionDefault
User Object Class This attribute indicates the LDAP object class that holds user information person
User Name Attribute This setting specifies the name of the attribute within the LDAP user object that holds the username. uid
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. subtree
User From Name Filter This attribute specifies a search filter for finding a user given the username. "(&(uid=%u)(objectclass=person))"

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 (say) ou=groups, 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

SettingDefault
Static Group Object Class groupofuniquenames
Static Group Name Attribute cn
cn Group Search Scope subtree
Group From Name Filter "(|(&(cn=%g)(objectclass=groupofUniqueNames))(&(cn=%g)(objectclass=groupOfURLs)))"

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

SettingDescriptionDefault
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. member
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. (&(uniquemember=%M)(objectclass=groupofuniquenames))

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:

  1. Create an Administrators group in the LDAP repository and place the LDAP user, which is associated with WebLogic's boot identity, in this group.

  2. 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. UserNameMapper interface, and also must be available in WebLogic's CLASSPATH during startup.
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.

Pages: 1, 2, 3, 4, 5, 6, 7, 8

Next Pagearrow