Managing Application Security
In this section, we present a brief overview of the setup, management, and administration of the WebLogic Server application security features. We start with a brief review of the J2EE standard security settings in various deployment descriptors. Next , we will show you how to set up roles and access control policies using the built-in WebLogic Security providers capabilities. We finish by talking about the different ways to specify the username and password needed to boot the WebLogic Server.
Setting Up J2EE Application Security
In this section, you will learn how to use J2EE security mechanisms to set up authentication requirements, configure access control policies, and define role mappings for Web applications, Enterprise JavaBeans (EJB), resource adapters, and enterprise applications. We will cover Web Services security in Chapter 15 after we have covered WebLogic Server s Web Services container in more detail.
With most J2EE components types, WebLogic Server uses a two-level process for mapping roles defined in the J2EE standard deployment descriptors to actual WebLogic users or groups in the WebLogic Server-specific deployment descriptor. This mechanism allows you to use standard role names in your application and then map them to physical users or groups at deployment time.
Securing Web Applications
When setting up Web application security, the first decision you need to make is the type of HTTP authentication mechanism to use. In the following web.xml deployment descriptor, we define the desired HTTP authentication mechanism in the auth-method element, within the login-config element:
<login-config> < auth-method > FORM < /auth-method > <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login_error.jsp</form-error-page> </form-login-config> <realm-name>BigRez Realm</realm-name> </login-config>
This tells the Web container that the Web application will be using form-based authentication. Three different types of authentication are supported:
BASIC. Using this method causes the Web browser to pop up the HTTP authentication dialog box requesting a username and password. To define basic authentication in your Web application, simply replace FORM with BASIC in the auth-method element and eliminate the entire form-login-config element. The realm-name tag is used only with BASIC authentication to specify the authentication realm displayed in the browser s pop-up authentication dialog box. It is completely cosmetic and has no other purpose at this time.
FORM. When using form-based authentication, the browser is redirected to the configured HTML login form, as defined in the < form-login-page > element, whenever the user tries to access a protected URL. Once authentication succeeds and authorization is granted, the Web container automatically redirects the browser to the originally requested HTTP resource, complete with its original HTTP headers. If this authentication fails, the browser will be redirected to the HTTP resource defined in the < form-error-page > element. When using form-based authentication, your form must use the j_username and j_password form element names to identify the username and password attributes to the container. The form s action attribute must be set to j_security_check , as shown here. These form element and action names are required by the Java Servlet specification:
<form method="POST" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input type="submit" name="Login"> </form>
CLIENT-CERT. If you are using two-way SSL between the browser and the server, you can choose client certificate-based authentication. This option requires not only two-way SSL connections but also the use of an appropriate identity asserter to map the certificate to a WebLogic Server username, as we discussed at length in earlier sections of this chapter. To specify client certificate-based authentication, simply replace FORM with CLIENT-CERT in the auth-method element. When using this type of authentication, the form-login-config and realm-name elements may be omitted.
It is important to remember that with any of these authentication options, the container will not authenticate the user until the browser tries to access a protected URL. While this seems intuitive with either basic or form-based authentication, it also applies to client certificate-based authentication. This means that even though the SSL handshake is complete and the client certificate is available to the server, WebLogic Server will not invoke the identity asserter until you try to access a protected resource.
Because the security realm is defined at the domain level, all Web applications on the server use the same authentication realm. By default, WebLogic Server uses the same cookie name ( JSESSIONID ) for all Web applications on the server. That way, no matter what type of authentication method is used in a particular Web application, an authenticated user will have single sign-on to all other Web applications in the WebLogic Server. You can modify this behavior by changing the cookie path or cookie name for specific Web applications. The following extract from the weblogic.xml deployment descriptor shows how to modify the cookie name. To modify the cookie path instead, simply change the param-name element from CookieName to CookiePath :
<session-descriptor> <session-param> <param-name>CookieName</param-name> <param-value>ApplicationSpecificCookieName</param-value> </session-param> </session-descriptor>
Now that you have set up the authentication mechanism, you are ready to set up the access control policies and roles for the Web application. The policies themselves are specified exclusively in the web.xml deployment descriptor within the security-constraint element, as shown here:
<security-constraint> <web-resource-collection> <web-resource-name>SecureArea</web-resource-name> <description>Our Secure Area</description> <url-pattern> /secure/* </url-pattern> <http-method> POST </http-method> <http-method> GET </http-method> </web-resource-collection> <auth-constraint> <description>Constraints for secure area</description> <role-name> manager </role-name> <role-name> security-admin </role-name> </auth-constraint> <user-data-constraint> <description>SSL is not required</description> <transport-guarantee> NONE </transport-guarantee> </user-data-constraint> </security-constraint>
As the bold highlighting shows, all HTTP POST and GET requests for any URL matching the pattern /secure/* relative to the root context of this Web application will be protected. It s typical to always define both GET and POST here, unless there are some very special circumstances in your particular Web application. We have restricted access to these resources so that only users in the role manager or security-admin can access them, but we are not requiring the use of SSL transport for access. Setting the transport-guarantee to CONFIDENTIAL would further restrict access to only those users in one of the specified roles who are using SSL to access the page.
| Best Practice | When restricting resources always protect against both HTTP GET and POST unless your application has special requirements that do not allow them. Even if your application uses only one method to access the resource, protecting against both methods will prevent unintended access by determined users. |
Now, you need to declare the roles used in the auth-constraint elements, using the security-role elements:
<security-role> <description>the managers role</description> <role-name>manager</role-name> </security-role> <security-role> <description>the security-admin role</description> <role-name>security-admin</role-name> </security-role>
If we stopped here, WebLogic Server would try to map these roles to principals, either users or groups, with the same name, as defined in the active security realm s authentication provider. In most cases, you don t actually want this so you need to define the mapping from these roles to actual principals defined in the WebLogic Security realm.
To map these roles to principals in the underlying security realm, you use the security-role-assignment element in the weblogic.xml deployment descriptor. As our example here shows, we are mapping the manager role to the Administrators group and the security-admin role to three unique users: paulb , rpatrick , and billjg .
<security-role-assignment> <role-name> manager </role-name> <principal-name> Administrators </principal-name> </security-role-assignment> <security-role-assignment> <role-name> security-admin </role-name> <principal-name> paulb </principal-name> <principal-name> rpatrick </principal-name> <principal-name> billjg </principal-name> </security-role-assignment>
We should point out that changing these role mappings in the weblogic.xml deployment descriptor requires that you redeploy the application for the changes to take effect. In most cases, you will want to map roles to groups defined in the underlying realm so that you can dynamically change who has access to your protected resources by simply changing the group membership in the underlying security realm.
| Best Practice | Always explicitly specify the mapping of your deployment descriptor roles to principals in the underlying security realm. In most cases, you will want to map these roles to groups, rather than users, to allow you to dynamically change who has access to protected resources without redeploying the application. |
Web applications also support the ability to run the application always as a specific principal, regardless of any authentication that may have occurred. This is an alternative to the authentication and protection mechanisms already discussed. To configure your Web application to run as a specific principal, you first need to specify the role using the run-as element in the web.xml deployment descriptor, as shown here. This declaration will tell the container to run the Web application always as the AppAdmin role.
<run-as> AppAdmin </run-as>
Next, we want to specify the mapping of the role to a specific principal in the underlying security realm. The best way to do this is to use the run-as-role-assignment element in the weblogic.xml deployment descriptor, as shown here:
<run-as-role-assignment> <role-name> AppAdmin </role-name> <run-as-principal-name> lauren </run-as-principal-name> </run-as-role-assignment>
This mapping applies for the entire Web application. If the run-as-role-assignment is not defined for a given role, the container will choose the first principal name defined for that role in the security-role-assignment stanza.
It is also possible to scope the run-as configuration to a specific servlet in the Web application. This servlet-scoped run-as-principal-name configuration overrides the more general one specified using the run-as-role-assignment stanza. In this example, we will always run the SampleServletName servlet as the user hugh in the underlying realm:
<servlet-descriptor> <servlet-name> SampleServletName </servlet-name> <run-as-principal-name> hugh </run-as-principal-name> ... </servlet-descriptor>
If needed, you can use programmatic security checking in the business logic of your Web applications. While we will not bother to go through all of the servlet security- related APIs, one interesting method to point out is the isUserInRole() method:
boolean isUserInManagerRole = request.isUserInRole(manager)
Using this method, you can test whether the current user should get certain types of options or data. By defining this role and mapping it to one or more principals in the Web application deployment descriptors, the application code can do fine-grained security checks without sacrificing the level of indirection that role mapping gives you. The bigrez.com application used this technique to control the list of properties displayed to a user based on his or her role.
Just to be complete, there is another way to restrict what a Web application can do by using JAAS authorization policies. As discussed previously, JAAS authorization typically uses a policy file to store its authorization policies. This policy file specifies a set of Java run-time permissions based on where the code originated. Because that file doesn t know where the deployed Web application will exist on the server s filesystem, the CodeBase cannot be statically defined. As a result, you cannot define a JAAS authorization policy for Web applications in the server-wide weblogic.policy file. To get around this limitation, WebLogic Server allows you to define a JAAS authorization policy for a Web application in the weblogic.xml deployment descriptor. This example shows how to restrict the Web application s java.net.SocketPermission to allow it to connect only to the BEA Web site:
<security-permission> <description> Connect permission to BEA Web site</description> <security-permission-spec> grant { permission java.net.SocketPermission www.bea.com:80, connect }; </security-permission-spec> <security-permission> As we alluded to earlier, most applications running on a server can be audited by other means to make sure that they are not doing something they shouldn t. The run-time overhead of JAAS authorization is high so we recommend very careful consideration and performance testing before going too far down this path.
| Warning | JAAS authorization provides very fine-grained, system-level control of Java run-time resources. This system-level control comes at a high price in run-time overhead. Always prototype and performance test any application making use of JAAS authorization before committing to that approach. |
Managing EJB Security
To set up an access control policy in an EJB, you use the security-role and method-permission elements of the ejb-jar.xml deployment descriptor. In the following example, we restrict access to the AdvertiseProduct EJB s getResults() method to users in either the manager or ejb-admin roles:
<assembly-descriptor> <security-role> <role-name> manager </role-name> <role-name> ejb-admin </role-name>_ </security-role> <method-permission> <role-name> manager </role-name> <role-name> ejb-admin </role-name> <method> <ejb-name> AdvertiseProduct </ejb-name> <method-name> getResults </method-name> </method> </method-permission> ... </assembly-descriptor>
EJBs also support the concept of role mapping. Similar to Web applications, the application server-specific deployment descriptor, weblogic-ejb-jar.xml , contains the actual mapping data. The following example maps the manager role to both the Administrators group and the user paulb . Additionally, you can use the externally-defined element to force a role to be defined in the Role Mapper security provider; this externally-defined tag replaces the old global-role tag:
<security-role-assignment> <role-name> manager </role-name> <principal-name> Administrators </principal-name> <principal-name> paulb </principal-name> </security-role-assignment> <security-role-assignment> <role-name> ejb-admin </role-name> < externally-defined/ > </security-role-assignment>
As you might expect, EJBs also support the ability to run as a specific principal. Similar to Web applications, we start by specifying the run-as role in the ejb-jar.xml , as shown in the following example where we set the run-as role to EJBAppAdmin :
<security-identity> <run-as> EJBAppAdmin </run-as> </security-identity>
Now, we map the specified run-as role to a specific principal using the run-as-role-assignment tag in the weblogic-ejb-jar.xml deployment descriptor. Here, we map the EJBAppAdmin role to the user bob :
<weblogic-ejb-jar> ... <run-as-role-assignment> <role-name> EJBAppAdmin </role-name> <run-as-principal-name> bob </run-as-principal-name> </run-as-role-assignment> </weblogic-ejb-jar>
We can also scope the run-as configuration to a specific EJB within the jar file, as shown in the code that follows , where we map the run-as role to the user jason for the BandEJB . As before, this EJB-scoped run-as-principal-name configuration overrides the more general one. If there is no run-as-principal-name element specified in either place, the container will match the run-as role to the first principal listed in the normal role mapping elements:
<weblogic-enterprise-bean> <ejb-name>BandEJB</ejb-name> ... <run-as-principal-name> jason </run-as-principal-name> </weblogic-enterprise-bean>
You can use programmatic security checking in the business logic of an EJB. This can allow for business logic with very specific requirements to test whether the current user should get certain types of information. To get the currently authenticated user, use the getCallerPrincipal() method:
Principal currentUser = ejbContext.getCallerPrincipal();
To check whether the currently authenticated user has a specific role, use the isCallerInRole() method:
boolean isUserInRole = ejbContext.isCallerInRole("manager"); WebLogic EJBs also support using JAAS authorization policies in the weblogic-ejb-jar.xml deployment descriptor to restrict the system-level resources an EJB can use. To do this, you use the security-permission element, whose syntax is exactly the same as that of the security-permission element in the weblogic.xml deployment descriptor entry. For the same reasons, we caution you against trying to use JAAS authorization without first proving to yourself that the benefits are worth the costs.
Securing J2EE CA Resource Adapters
J2EE Connector Architecture (J2EE CA) resource adapters store their security configuration in the ra.xml and weblogic-ra.xml deployment descriptors. Using the weblogic-ra.xml , you can define the mapping between the authenticated application server user and the username and password to use to connect to the underlying resource:
<security-principal-map> <map-entry> <initiating-principal>WLSuser</initiating-principal> <resource-principal> <resource-username>EISuser</resource-username> <resource-password>EISpasswd</resource-password> </resource-principal> </map-entry> </security-principal-map>
It is important to note that this mapping has been deprecated in favor of the WebLogic Security framework s Credential Mapper, which supports dynamic changes and persists the mapping information to a more secure data store.
| Best Practice | Use the Credential Mapper to map WebLogic security principals to the username and password to use to connect to the underlying resource. |
Securing Enterprise Applications
One problem with defining roles in the Web application and EJB components is that you may need to define them in multiple places. Enterprise applications can define roles that apply to all of their containing components in their application.xml deployment descriptor. This allows application-scoped role definitions using the same techniques as Web applications and EJBs.
For enterprise applications, weblogic-application.xml is the WebLogic Server-specific deployment descriptor used to define application-scoped configuration information. The descriptor offers little in terms of security configuration. It does not currently allow you to define any role mappings. This means that you would have to map any roles defined in the application.xml to the underlying principals using the individual Web application and EJB deployment descriptors or using the global Role Mapper provided in the security framework.
Although the weblogic-application.xml deployment descriptor provides a realm-name element that is said to allow you to specify the security realm that the application should use, this parameter has no real use except as a way of preventing an application from trying to start if the wrong domain-wide security realm is active.
Setting Up WebLogic Application Security
This section begins with a very brief discussion of how to create and manage WebLogic Server users and groups because every application that uses application-level security will need to do this. Next, we will talk about roles, both application-scoped and global. From there, we will explain setting up access control on specific server resources and then forming a set of policies. We will end this section with a brief explanation of how to set up single sign-on across WebLogic Server domains.
Managing Users and Groups
If you are using the default configuration ”which uses WebLogic embedded LDAP Server as the security store ”then you can manage users and groups using the WebLogic Console. By navigating to the Security- > Realms- > myrealm folder in the left navigation bar, you will see entries for Users , Groups , and Roles . Selecting Users or Groups displays pages that allow you to add, delete, modify, and view different users or groups in the domain. Each user and group must be uniquely identifiable in a WebLogic Server domain. Because users and groups are identified only by their names and a WebLogic Server Principal can refer to either a group or user, every user and group must have a unique name.
In previous versions of WebLogic Server, there were a default set of users and groups that are no longer present in newer versions of the server. Three such built-in users and groups warrant further discussion: the guest and system users and the everyone group.
The guest user was used to represent any unauthenticated user; its default password was guest . By changing the guest user s password to something else, you could effectively disable anonymous access to the server. Unfortunately, there was a loophole that still allowed you to create a new JNDI InitialContext without supplying a username and password unless you had explicitly protected the JNDI tree with an access control list (ACL). This allowed effective anonymous access, even though the guest user was turned off.
Fortunately, the introduction of the new security service, which first appeared in WebLogic Server 7.0, fixed this problem. The guest user no longer exists, and any unauthenticated access to the server runs as user < anonymous >, which the authorization providers can check for. If you really need to use the guest user scheme, you can re-enable it by setting the weblogic.security.anonymousUserName Java system property to guest on the command line.
If you are familiar with older versions of WebLogic Server, you will remember the everyone group that was used in ACLs to allow access to any user in the domain. This built-in group no longer exists in the new security service and has been replaced by the Anonymous role.
Finally, older versions of WebLogic Server had the notion of the system user. This user was the administrator for the entire domain, but its username could not be changed from system . Starting in WebLogic Server 7.0, this administrative user has been redefined through the use of the Admin role, which by default is granted only to members of the Administrators group. As part of this change, administrative functions have been subdivided into several functional categories and assigned to global roles, which we ll discuss in the next section.
Before moving on, we should mention WebLogic Server s User Lockout feature. By default, a user has five attempts to enter the correct password before being locked out of the server. You can adjust the user lock-out characteristics using the Security- > Realms- > myrealm folder s User Lockout tab. Anyone with the Admin role can unlock the user prior to the time-out. To unlock a locked-out user, use the WebLogic Console to navigate to the appropriate server in the left-hand navigation bar and then choose the server s Security Monitoring tab. Enter the username in the Unlock User field, and press the Apply button.
Working with Roles and Policies
There are two types of roles, global roles and scoped roles. Scoped roles are specific to a particular application component like an EJB or Web application, an entire enterprise application, or a specific resource like a JDBC connection pool. As we discussed in the Setting Up J2EE Application Security section, J2EE deployment descriptor roles are scoped roles unless specified as externally defined. WebLogic Server uses these scoped roles only when making access control decisions about the target object that defines the role s scope. This is different from a global role, which applies to access control decisions anywhere in the server, regardless of the application or resource.
Using the WebLogic Console, we can define both global and scoped roles. Going back to the Security- > Realms- > myrealm folder where we previously looked at the Users and Groups folders, we can also see the default set of global roles, as well as the default groups used to map them. Because this data is associated with the default security providers, it is stored only in the embedded LDAP server. Table 10.4 explains the default roles and group mappings.
| DEFAULT GLOBAL ROLES | ACCESS POLICY | DEFAULT GROUPS |
|---|---|---|
| Admin | All access to the console. This means deploying applications, startup and shutdown classes, Web Services, and J2EE connectors. It can also modify server configuration and edit deployment descriptors. | Administrators |
| Deployer | May deploy applications, startup and shutdown classes, Web Services, and J2EE connectors. It may view the server configuration. | Deployers |
| Operator | Start, stop, and resume servers. It may view the server configuration. | Operators |
| Monitor | View the server configuration. | Monitors |
| Anonymous | Similar to the old everyone group, this role implies all users, authenticated or not. | Everyone |
| No Matching Role | Any authenticated user. | Users |
Each default administrative role has a mapping to a specific default group. If a user is a member of that group, they are in the matching role. As you can see, the default role names are all singular while the default group names are plural. This is done solely to make it easier to differentiate which names are roles and which names are groups.
| Best Practice | Keeping role names singular and group names plural will help make security discussions involving roles and groups less confusing. |
Take a look at one of the default global role definitions. This can be found under the Conditions tab of a specific global role s page in the WebLogic Console. Currently, there are only three options for expressing the definition of a role: a username, a group name, or the time of day. You can modify the order of the qualifying expressions, but all must be true for a user to be considered in a role. You can easily define a new global role in the default security provider via this Global Roles page.
We can also use the WebLogic Console to create application- or resource-scoped roles by right-clicking on the application or resource in the left-hand navigation tree and selecting the Define Role menu option in the pop-up menu. Using this same pop-up menu, you can define access control policies for the applications and services. In addition to the EJB resources and Web application resources that we ve discussed so far, you can define access control policies for many other types of resources in the server including administrative resources, which apply to control of the WebLogic Console, deployment of applications, and other actions. Some of the resources include jCOM resources, EIS resources, JMS resources, JDBC resources, JNDI resources, MBean resources, and Web Services resources, all of which control access to their specific server services.
Access control policy is hierarchical. For example, a policy set on all Web applications will apply to any specific Web applications. To make certain you always know the entire policy for a specific application, there is a section called Inherited Policy Statement on the Console s Policy Definition page. You can even define a scoped role and policy to a branch of the JNDI tree. Simply use the WebLogic Console to select a server and use either the pop-up menu or the link at the bottom of the server s configuration pages to select View JNDI tree . Table 10.5 shows the default security policy for the server.
| WebLogic Resource | Default Security Policy |
|---|---|
| Administrative resources | Roles: Admin, Deployer, Operator, Monitor |
| Server resources | Roles: Admin, Operator |
| COM resources | Role: jCOMRole |
| EIS resources | Role: Anonymous |
| EJB resources | Role: Anonymous |
| JMS resources | Role: Anonymous |
| JDBC resources | Role: Anonymous |
| JNDI resources | Role: Anonymous |
| MBean resources | Role: Anonymous |
| Web Service resources | Role: Anonymous |
Now that you know how to define both global and scoped roles and access control policies using both the WebLogic Console and J2EE deployment descriptors, you need to understand the persistence of this information. For deployment descriptors, it s easy to see that the persistence mechanism is the deployment descriptor itself. For the WebLogic Console, roles and policies are stored using the default security provider s store. If you are using a custom provider, you cannot use the WebLogic Console to manage roles and policies.
The new security framework can consume the role definitions in the deployment descriptors and merge them with the globally defined roles in the underlying Role Mapper security provider. There are a few options you can use to explicitly define that merging process. With the default server configuration, WebLogic Server reads the deployment descriptor role and policy information and integrates it into the default security provider s configuration. This makes the information immediately visible in
the WebLogic Console. If at this point you use the WebLogic Console to modify the application s role or policy configuration in any way, the WebLogic Security Service will persist this modified information into the default security provider rather than into the deployment descriptors. Regardless of how you define the role, the server will always calculate the role membership at run time, so they are very dynamic.
If you are not careful, the complexity of the merging and storing of role and policy definitions can get you into trouble. We recommend that you come up with a simple plan that specifies where the role mapping and policy information will live and stick to it.
| Best Practice | Define a simple set of guidelines for where you will define the roles and policies your application needs and then stick to them to reduce confusion resulting from the WebLogic Server s complex merging policies. |
To summarize, you have four different ways to restrict access to Web applications and EJBs:
Use only the J2EE Deployment Descriptors. WebLogic Server reads the roles and policies information from the deployment descriptor at deployment time and uses it throughout the life of the application. Using this option, you define users and groups using the WebLogic Console but define the roles, policies, and the mapping of roles to principals using J2EE deployment descriptors. If you need to modify the access control information at run time, this is typically done by modifying the group membership to one or more groups that are mapped to the relevant roles in the deployment descriptors. In WebLogic Server 8.1, the default configuration checks roles and policies only for Web applications and EJBs that have these configured via deployment descriptors.
Use only the WebLogic Console. In this case, the server maintains all of the access control information based on the information you enter using the WebLogic Console. To prevent accidentally picking up any deployment descriptor information that might be present, you need to change the default setting on the realm. To do this for WebLogic Server 8.1, go to the Security- > Realms- > myrealm folder and set the Check Roles and Policies for attribute to All Web applications and EJBs and the On Future Redeployments attribute to ignore roles and policies from DD prior to deploying any applications.
Seed the roles and access control policies with values from the deployment descriptors and then use the WebLogic Console to modify it from that point forward. To set this up, you need to set the Check Roles and Policies for attribute to All Web applications and EJBs and the On Future Redeployments attribute to initialize roles and policies from DD before deploying the application and then reset On Future Redeployments to ignore roles and policies from DD after deploying the application. Unless you reset this switch before redeployment, the data will get reinitialized every time you redeploy the application. From this point on, you will use the WebLogic Console to modify roles or access policies.
Configure the policies in the deployment descriptors but configure the role-to-principal mapping in the console. With this fourth option, you use the ejb-jar.xml or web.xml to set up the access control policy for specific roles but use the weblogic-ejb-jar.xml or weblogic.xml to specify that the roles map to a global role using the < externally-defined/ > element rather than a formal principal mapping. With this option, you do the role mappings only with the WebLogic Console.
While it is easy to define scoped roles and policies with the WebLogic Console, it is currently hard to manage such roles and policies. While the scoped roles are now visible through the console, there is currently no way for you to view the policies after initially defining them.
| Best Practice | Until WebLogic Server provides better management capabilities for these console-defined scoped roles and policies, use J2EE deployment descriptors for access control policies. |
Be aware that in WebLogic Server 7.0 and 8.1, none of these console-defined roles or policies will ever be used unless you set the weblogic.security.fullyDelegateAuthorization Java system property to true on the Java command line.
| Warning | In WebLogic Server 7.0 and 8.1, you must set the Java system property weblogic.security.fullyDelegatedAuthorization to true on the command line in order to use WebLogic Console-defined roles or policies. |
Booting WebLogic Server
When you start a WebLogic Server, it needs a username and password for a user in the Admin role. Because this username and password will authenticate a user in the Admin role, it is vital to keep this information as secret as possible. There are several different ways to make the username and password available to the server for booting.
The first way, and the most simple way, is to specify nothing on the command line. This will cause the server to prompt for a username and password in the shell. This may be acceptable for development purposes, but it has an obvious drawback for production systems where you do not want to rely on human intervention to start the server. You can also provide the username and password through Java system properties specified either as command-line arguments, as shown here, or programmatically using a Java program that wraps the call to weblogic.Server.main() :
java -Dweblogic.management.username=bauersc -Dweblogic.management.password=password ... weblogic.Server
Of course, this is not an elegant solution for a production system either because the command-line arguments may be seen by users having access to the operating system ”for example, by using the UNIX ps command to list the processes running on the machine.
The preferred way to provide the username and password is to use the boot.properties file, stored in the domain s root directory. This file contains the boot identity in an encrypted form. Both the username and password are encrypted with the Triple DES algorithm. If you set the weblogic.system.StoreBootIdentity Java system property to true, the server will use the supplied boot information to create the file for you. The easiest way to create the file, however, is simply to create a two-line text file that looks like the one shown here for a server using the system username with a password of insecure :
username=system password=insecure
In WebLogic Server 8.1, the WebLogic Configuration Wizard will automatically create this file for you when creating a new domain that uses development mode. We will talk more about development mode in the next chapter.
After creating this file manually, simply start the server once and it will encrypt the values of the username and password. If you want to rename the file to something less obvious, you can use the weblogic.system.BootIdentityFile Java system property to specify the name of the boot.properties file. Finally, you can tell the server to delete the file after it uses it. You might use this in conjunction with a shell script that copies the file from a secure location to the local directory just prior to starting the server. Setting the weblogic.system.RemoveBootIdentity Java system property to true will tell the server to delete the file:
java -Dweblogic.system.RemoveBootIdentity=true ...
| Best Practice | Use the boot.properties file mechanism to specify the server s boot identity on startup. |
EAN: 2147483647
Pages: 125