WebLogic Security Framework
This section will discuss the WebLogic Security Framework in detail, with particular emphasis on the out-of-the-box functionality. As you may have noticed in Figure 10.1, WebLogic Server ships with an embedded LDAP server. This server is used by the default security providers to store security- related information. Our first topic in this section is the embedded LDAP server. Next, we present an overview of the default security providers. Because these providers are fairly complex, we will cover only some of the more important features. For more detailed information, please refer to the WebLogic Server Security documentation at http://edocs.bea.com/wls/docs81/security.html. We will finish up this section with a discussion of how to use the Realm Adapter to run some of the pre-WebLogic Server 7.0 security realms in compatibility mode.
Embedded LDAP Server
WebLogic Server s default security providers use an embedded LDAP server to persist all security-related data. This data is stored locally on each server and includes all of the user , group , role, access control policy, and credential information. For each domain, the admin server acts as the master LDAP server and replicates new information to the managed servers LDAP servers once every 30 seconds. Each LDAP server does automatic backups of the entire LDAP directory tree once a day. You can configure the time that the backup task kicks off with the Backup Hour and Backup Minute parameters found on the Security folder s Embedded LDAP Configuration tab in the WebLogic Console. All backup files are compressed and stored with the LDAP server s data files; the maximum number of backup files the server will keep is also configurable through the same Embedded LDAP page in the console.
Whenever a WebLogic Server is started, it places all of its internal files in a server instance-specific directory. By default, the server s directory is located in the directory it was started from and has the same name as the server instance (for example, user_projects/mydomain/myserver ). Inside this server directory is an ldap subdirectory where you will find the LDAP server s files. Table 10.1 shows the full directory structure and description of the embedded LDAP server directory contents. If you ever encounter a problem where a managed server won t start and you suspect that its LDAP data may be corrupt, you can either try to use one of the backup zip files from the backup directory to revert the contents of the ldapfiles directory or simply remove the entire ldap directory and let it be recreated when the managed server starts up and connects to the admin server.
| DIRECTORY | INFORMATION STORED |
|---|---|
| backup | Zipped backup files created once a day from the ldapfiles directory |
| conf | Configuration files that are generated on the first server start |
| ldapfiles | LDAP server data files |
| log | LDAP server log files |
| replicadata | Managed server replicated data |
Within the ldapfiles directory, you will find seven data files. EmbeddedL-DAP .tran , EmbeddedLDAP.trpos , and EmbeddedLDAP.twpos are the transaction tracking files. If there is ever an internal problem with the embedded LDAP server these files may be deleted without loss of data. EmbeddedLDAP.data is the main data file where all the users, groups, roles, and policies are stored. EmbeddedLDAP_.delete contains information about deleted entries, and EmbeddedLDAP.index is the index of data files. Finally, the EmbeddedLDAP.lok file is used to ensure access consistency to the LDAP information. In some cases, a WebLogic Server might shut down without allowing the embedded LDAP server to unlock the data. If this happens, the server will go into a loop, waiting for the file to be removed and printing out a warning message:
<Apr 1, 2003 11:18:28 PM CST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: .\myserver\ldap\ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>
Typically, deleting the EmbeddedLDAP.lok file will resolve this issue.
WebLogic Server stores the default security providers default configuration information in a set of files with the ldift extension. Most of these files are located in the $WL_HOME/server/lib directory, though you will also see a couple of these ldift files in your WebLogic Server domain s root directory. WebLogic Server runs these ldift files through a preprocessor to convert them into standard LDAP ldif files that can then be fed directly into the embedded LDAP server.
The embedded LDAP server listens on the normal WebLogic Server listen port. Because the WebLogic Server installation program automatically generates a random, unique password for the LDAP server, this does not pose any significant security threat. You should avoid changing this password unless you absolutely need to because the generated password is typically harder to crack than ones you might normally choose. If you need to access the embedded LDAP server using standard LDAP mechanisms, you will need to change the security credential. You can change the embedded LDAP server s credential through the same Embedded LDAP console page we previously discussed. Once you have set this credential to a known value, you can use any LDAP tool to access the server s LDAP directory by setting the Base DN to the pattern dc= < your_domain_name >, the username to cn=Admin , and the password to the value used to set the credential through the WebLogic Console.
The embedded LDAP server uses replication between the administration server and any managed servers. This replication uses the server s SSL port, if it is enabled. Therefore, if you are concerned about the security of your LDAP replication data flowing between the administration server and any managed server, you should configure and enable SSL on all servers in the domain. We will talk about how to enable and configure SSL a little later.
| Best Practice | If the network connecting the WebLogic Servers in your domain is not trusted, make sure you enable SSL on each server in the domain so that WebLogic Server may use SSL for all LDAP replication between the Admin server and all managed servers. |
Default Security Providers
WebLogic Server ships with default providers that plug into the security framework. In this section, we will begin by looking at the default providers in more detail. We will briefly look at how to set up new providers and discuss when you might want to do that. Finally, we end this section with a look at how to manage these default providers using the JMX capabilities of WebLogic Server.
Let s start by looking at the different types of security providers. Table 10.2 shows the different types of providers and explains their functionality. To see the security providers running in your server, use the WebLogic Console to navigate to the Security- > Realms- > myrealm- > Providers folder in the left navigation bar.
| PROVIDER TYPE | FEATURES |
|---|---|
| Authentication | The default security provider allows for username-and-password-based, direct-to-server certificate-based, and HTTPS certificate-based authentication. The authentication provider gives the server a JAAS configuration that points at a specific JAAS LoginModule . |
| Identity Assertion | This security provider maps an outside authentication token to a username. This allows for things like perimeter authentication. It is part of the authentication provider. |
| Authorization | This security provider decides whether an authenticated Subject may access a set of resources given a certain application context. |
| Adjudication | When multiple authorization providers are configured, this provider tallies the decisions and decides on the final verdict of authorization. It is unnecessary if there is only one authorization provider. |
| Audit | This security provider collects and stores the security logs. |
| Role Mapper | After a Subject is authenticated, as it tries to access resources, the Role Mapper decides what roles apply to the Subject and stores them in the Subject object. |
| Credential Mapper | This security provider supplies the credentials for legacy systems to an authenticated Subject when needed. |
Figure 10.3 describes the typical call flow to those security providers.
Figure 10.3: Authentication and authorization call flow.
WebLogic Server loads the default security providers from two Java archive files in the server/lib/mbeantypes directory, wlSecurityProviders.jar and wlManagement.jar . These files contain not only the default security provider implementation classes but also their JMX configuration MBeans. When loading the security providers, WebLogic Server does not load these files from the classpath, but rather dynamically loads them using an internal class loader.
Authentication
In addition to the preconfigured providers, WebLogic Server comes with several built-in, configurable authentication providers. At the time of writing, these options primarily include support for external LDAP servers; these include support for iPlanet (and SunOne), ActiveDirectory, OpenLDAP, and Novell LDAP Servers. If you want to use an external LDAP server as your sole authentication provider, you must map WebLogic Server s Admin role to at least one group or user. By default, this Admin role maps to the Administrators group, so simply defining an Administrators group in your external LDAP tree is sufficient.
Also included in the list of built-in providers is the RealmAdapter , which can be used to plug in an old WebLogic Security Realm built against the old security realm SPIs. We will discuss the RealmAdapter in more detail in the compatibility mode overview at the end of this section. If you are familiar with the built-in authentication of earlier versions of WebLogic Server, you will notice that some previously supported providers are not currently supported. These include native Windows domain authentication, native UNIX PAM authentication, and database-based authentication. Currently, the only way to use these providers is either by using the old security realms in the compatibility mode or by writing your own authentication provider. The new MedRec example that ships with WebLogic Server 8.1 provides an example of how to build a new, custom authentication provider that uses a database for its security store.
WebLogic Server s security framework fully supports the Java Authentication and Authorization Service (JAAS) specification. JAAS specifies that all authentication is to be routed through a LoginModule interface. LoginModule s can be stacked together to form a pluggable framework. WebLogic Server s security framework supports multiple authentication providers in exactly the same way, thus allowing for multiple, pluggable providers. Each authentication provider supports one LoginModule; therefore, using multiple LoginModule s requires using multiple authentication providers. Each authentication provider has a configuration option called a control flag . This control flag allows the provider to specify how its authentication results affect the overall authentication process. These control flag options, which are the same as the JAAS LoginModule configurations that we will discuss in the Writing Java Clients That Use JAAS section later in this chapter, can have the following values:
Required. The authentication provider is required to succeed. If it succeeds or fails, the authentication process continues to proceed through the list of configured providers.
Requisite. The authentication provider is required to succeed. If it succeeds, the authentication process continues through the list of configured providers. If it fails, the authentication process immediately fails and returns control to the application.
Sufficient. The authentication provider is not required to succeed. If it does succeed, the authentication process succeeds and control immediately returns to the application. If it fails, the authentication process continues down the list of configured providers.
Optional. The authentication provider is not required to succeed. If it succeeds or fails, the authentication process continues down the list of configured providers.
When you create a new authentication provider, you should use a less strict control flag while in development. The primary reason is that a value of Required or Requisite will cause the authentication to fail if the new provider fails. Because the server must authenticate the administrative user used to start the server, a misconfigured provider using one of these strict control flags will prevent the server from starting. If the control flag is set to either Sufficient or Optional , the server will show you the error information about the incorrectly configured provider but will start, thus allowing you to use the WebLogic Console to modify the configuration. Once you verify that everything is working in the new provider, set the control flag to the desired value.
| Best Practice | Set the control flag for all authentication providers to OPTIONAL before applying any changes to prevent a configuration error from causing the server not to boot. |
The WebLogic Console now sets the default value for the Control Flag attribute to OPTIONAL . You should be aware, though, that the default value in the underlying MBean is still REQUIRED . This means that if you create the MBean by hand, through hand-editing of the config.xml or writing JMX programs, you need to explicitly set the Control Flag attribute or it will automatically be set to REQUIRED . Because most people use the WebLogic Console, this should not be a problem.
If you find yourself in a situation where your server will not boot because of a security realm configuration issue, you can recover a WebLogic Server 7.0 server by deleting the userConfig subdirectory found in the domain s root directory and starting the security provider configuration process over from scratch. Starting in WebLogic Server 8.1, you can simply edit the provider s config.xml entry to change the ControlFlag setting:
<weblogic.security.providers. authentication.OpenLDAPAuthenticator ControlFlag="OPTIONAL" Realm="Security:Name=myrealm" Name="Security:Name=myrealmOpenLDAPAuthenticator" />
Of course, you can also restore the config.xml from one of the backups that WebLogic Server automatically makes.
When using an external LDAP authentication provider, you might want WebLogic Server to continue to serve any unprotected information even when it cannot get authentication information from the external LDAP server, such as when the LDAP server is unavailable. To accomplish this, you must make certain the server s boot identity is defined in the embedded LDAP server, so it can be used whether or not the external LDAP server is operational. You can use the WebLogic Console to set connection and search result time-out values on the external LDAP authentication provider. This will ensure that the server does not hang when attempting to authenticate against the external LDAP server. Following these steps will allow you to boot and serve up unprotected information with the WebLogic Server even when your external LDAP server is unavailable.
| Best Practice | When using an external LDAP provider, it is a good idea to store the server s boot identity in the embedded LDAP server. By doing this and setting time-outs on the external LDAP authentication provider, you can continue to boot and serve up unprotected information with WebLogic Server when the external LDAP server is unavailable. |
Before we move on to talk about identity assertion, we should talk about what to do if you forget your administrative password and cannot boot the server. Please note that the following procedure works only for the default authenticator using the embedded LDAP server and only if you have not modified the global Admin role, which by default is granted to the Administrators group. For our example, we will assume that your server name is myserver . To reset the password, follow these steps:
-
Using the command line, change the directory to your WebLogic Server domain s root directory and run your setEnv script to set up your PATH and CLASSPATH .
-
Create a new initialization file for the default authenticator by creating a new DefaultAuthenticatorInit.ldift file in the current directory:
java weblogic.security.utils.AdminAccount <tempadmin> <temppassword> ./
-
Remove the initialized status file DefaultAuthenticatormyrealmInit.initialized from the myserver/ldap/ subdirectory.
-
Restart the server, and enter the < tempadmin > username and < temppassword > password supplied in step 2.
Identity Assertion
Identity asserters take an outside identity token, validate it, and map it to a valid WebLogic Server user. The default identity assertion provider, known as the DefaultIdentityAsserter , can validate WebLogic Security tokens, X.509 certificates, and IIOP CSIv2 tokens. By default, the DefaultIdentityAsserter is enabled only to support WebLogic Security tokens; use the WebLogic Console to enable support for the other supported token types. This default identity assertion provider does its work via a UserNameMapper interface, which maps either an X.509 certificate array or an X.501 distinguished name to a username. Using the WebLogic Console, you can enable and configure the Default User Name Mappe r that comes with the server to extract the username automatically from most fields in an X.509 certificate. You can also write your own username mapper implementation class by implementing the weblogic.security.providers.authentication.User_NameMapper interface and configuring the DefaultIdentityAsserter to use it. Of course, you can also write a custom identity assertion provider to support other types of tokens, such as Kerberos or SAML tokens.
Probably the two most common reasons to change the default configuration of the DefaultIdentityAsserter are to support authentication via client certificates from a two-way SSL connection or to support certificate validation for WebLogic Server s Web Services Security implementation. To enable identity assertion for X.509 certificates, first you need to add X.509 to the list of chosen types at the bottom of the General tab. Next, you need to enable and configure the Default User Name Mapper , currently found on the DefaultIdentityAsserter s Details tab in the WebLogic Console.
The Default User Name Mapper Attribute Type allows you to choose which field in the distinguished name (DN) of the Subject of the X.509 certificate to use to obtain the username. If the field being used contains more than the username, the Default User Name Mapper Attribute Delimiter can be used to truncate the extraneous information. For example, if you select the E value for the attribute type, you may need to strip off the domain name information from the email address. If the email address was bauersc@bigrez.com and the WebLogic Server username was bauersc , setting the delimiter to @ would allow the username mapper to map the email address field in the certificate to the correct WebLogic Server username properly.
It is important not to remove the DefaultIdentityAsserter because it handles the authentication context interoperability with prior versions of the WebLogic Server. It does this work via the AuthenticatedUser token in the Chosen Types box.
| Warning | The AuthenticatedUser token type supported by the DefaultIdentityAsserter plays a critical role in supporting authentication interoperability with earlier versions of WebLogic Server. Removing the DefaultIdentityAsserter will cause your domain to be unable to exchange authentication tokens with earlier versions of WebLogic Server. |
Before we leave the topic of identity assertion, we need to talk about cross-domain trust. When a WebLogic Server authenticates a user, it digitally signs the authentication context using its domain s shared secret credential. Any server with the same shared secret can accept the authentication context and participate in single sign-on (SSO) across J2EE applications deployed in different WebLogic Server instances, clusters, or domains.
In older versions of WebLogic Server, this shared secret credential was the system user s password. Starting with WebLogic Server 7.0, this shared secret credential is an automatically generated, domain-wide value, which is very random and almost certainly better than any password you might use. So, change this credential only if you absolutely must.
To enable two WebLogic domains to interoperate , you must set their shared secret credential to be the same value. You can set this value using the Security folder s Advanced Configuration tab to disable generated credentials and specify the actual credential to use. For interoperating with pre-WebLogic Server 7.0 releases, you will need to set the credential to the value of the system user s password for the older server.
Authorization and Adjudication
WebLogic Server s security framework supports the use of one or more authorization providers to make authorization decisions about whether a particular subject (authenticated user) may have access to a particular resource. When using multiple providers, it is possible that some providers may permit access while others either abstain or deny access. This is where the adjudicator comes in. An adjudicator looks at all of the responses from the different authorization providers and decides whether access is granted or denied .
When making authorization calls into the WebLogic Security Service, the server passes information about the identity of the caller, the resource being accessed, and other contextual information about the call to an AccessDecision object. The AccessDecision object will use this information to make its authorization decision. For example, when a caller tries to access a protected method of an EJB, an AccessDecision object could get access to the parameters that were used to call the method for which it is being asked to make an authorization decision. Having this additional contextual information about the request allows the AccessDecision object to make access decisions using arbitrarily complex security policies. Of course, the complexity of the authorization decisions depends on what type of contextual information the server provides for a given type of resource. We expect that the amount of information available to the authorization provider will expand over time to include just about anything that the provider could possibly want.
This contextual information is passed using objects that implement the weblogic.security.service.ContextHandler interface. A ContextHandler is essentially a list of name-value pairs. WebLogic Server s default authorization provider uses the information in the ContextHandler to decide whether a given subject may have access to a given resource. We hope that you will not need to write your own authorization provider because the default provider supports fairly complex policy statements. If you do, we encourage you to look at the Developing Security Providers for WebLogic Server documentation at http://edocs.bea.com/wls/docs81/dvspisec/index.html and the sample providers on the BEA developer s Web site at http://dev2dev.bea.com/direct/SampleSecurityProviders.zip for more information.
| Tip | If you need to extend or implement your own security providers, some very good example providers are available on the BEA developer Web site at http://dev2dev.bea.com/direct/SampleSecurityProviders.zip. These are source code examples of everything it takes to write a set of providers, and we highly recommend them. |
Unless you develop your own authorization provider, you may never need to use the adjudication provider. Even if you add a second authorization provider, the default adjudication provider can be configured to resolve almost any conflict.
Auditing
WebLogic Server s default audit provider simply sends security events to the DefaultAuditRecorder.log file in the domain s root directory. By default, this audit provider is disabled, so you will need to use the WebLogic Console to enable it. You could write your own audit provider to send security logs to a specialized, non- repudiation data store. To do this, your provider must implement the weblogic.security.spi.AuditChannel interface, which receives a weblogic.security.spi.AuditEvent whenever an audit message occurs.
Role Mapping and Credential Mapping
The default role mapper provider handles all the global and application-scoped role definitions, as described later in the Working with Roles and Policies section. This default provider also reads the role definitions from the deployment descriptors, by default. If multiple role mapper providers are specified, the resulting sets of roles returned from the providers are intersected to determine the set of applicable roles.
The credential mapper provider supplies credentials for legacy systems and EIS systems. It takes the arguments of the current authenticated subject, the legacy resource type, and the type of credential requested . The default credential mapper provider will most likely be sufficient for all your needs.
Similar to the ignore roles and policies from DD option discussed later in the Working with Roles and Policies section, there is a provider-specific flag to do the same thing. The authorization, role mapper, and credential mapper providers each have individual flags on their MBeans to adjust whether that specific provider will accept configuration information from the deployment descriptors. This requires extreme caution, and it should be left to the default value in most cases. Read the Working with Roles and Policies section for more information before changing these values on the providers themselves .
Managing Security Provider Configuration
WebLogic Server uses JMX MBeans to hold all of the security providers configuration data. When a new server is first configured, it will read the default security configuration information from $WL_HOME/server/lib/SecurityDefaultConfig.xml the first time is started. While all other server configuration MBeans are persisted to the config.xml file, WebLogic Server 7.0 persists the default security providers configuration MBeans into the userConfig subdirectory, under the domain s root directory. This configuration information contains only the information necessary to tell the booting server which security providers to use and the provider-specific configuration information of those providers. All security data is kept in either the embedded LDAP server or the provider s external data store. This duality of configuration persistence forms is obviously confusing. WebLogic Server 8.1 eliminates this duality, as you will see in a moment.
In addition, persisting the data in binary form makes it difficult to see the changes you make to the security providers outside of the WebLogic Console. It s also hard to stage servers without more insight into this binary data. You can convert this binary security configuration information into XML using the WebLogicMBeanDumper utility. For example, running the following command from the domain s root directory will dump all security MBeans into a new file called out.xml .
java weblogic.management.commo.WebLogicMBeanDumper name Security:* out.xml
Fortunately, WebLogic Server 8.1 moves the security provider MBean configuration data into the config.xml along with the rest of the server configuration MBean data; however, this does not rule out the possibility that third party security providers may still use this alternate binary persistence form. As a result, it is important to check with any third-party provider vendors you might be using to see where they persist their configuration data.
Most of WebLogic Server s default security providers have import and export facilities in the WebLogic Console. Currently, the most notable exception is the authentication provider, which has only an import facility. These facilities can be useful when trying to move from a development to a production environment, or to any other staged server setup. Although these facilities allow for more granular staging of the specific providers, it is probably much easier to simply copy the security MBeans and then copy the entire embedded LDAP tree and the SerializedSystemIni.dat file (which contains the server s encryption key and salt) to the new server.
You can gain programmatic access to the security providers through the WebLogic Security MBeans in the weblogic.management.security package. The following example, PasswordChanger , shows how to modify a user s password programmatically using the weblogic.management.security.authentication.UserPasswordEditor interface. A complete source code version of this program can be found on this book s companion Web site (http://www. wiley .com/compbooks/masteringweblogic).
public void changePassword(MBeanHome adminServerHome, String username, String oldPassword, String newPassword) throws InvalidParameterException, NotFoundException { DomainMBean domain = adminServerHome.getActiveDomain(); SecurityConfigurationMBean security = domain.getSecurityConfiguration(); RealmMBean realm = security.findDefaultRealm(); AuthenticationProviderMBean [] providers = realm.getAuthenticationProviders(); for (int i = 0; i < providers.length; i++) { if (providers[i] instanceof UserPasswordEditorMBean) { UserPasswordEditorMBean editor = (UserPasswordEditorMBean)providers[i]; editor.changeUserPassword(username, oldPassword, newPassword); System.out.println("Password for user " + username + " changed to " + newPassword + " in provider " + providers[i].toString()); } } } By looking through the Javadocs for these MBean interfaces, you can see how to manipulate both the default security providers and any third-party security providers that are capable of management. These methods are available only to programs running with the Admin role. We will talk more about the Admin role and the other default roles later in this chapter.
So far, all our discussions have assumed that you are using the default realm, called myrealm . As you can easily see from the WebLogic Console, it is possible to create and configure an entirely separate realm. A domain may run with only one active realm at a time. You can choose the active realm for a domain using the Default Realm attribute in the Security folder s General Configuration tab. Be aware that switching active realms can be dangerous. For example, if the new realm doesn t define any users in the Administrators group, the new server configuration cannot be managed by anyone and must be reverted.
We recommend testing the realm to verify its configuration before trying to switch realms. In WebLogic Server 8.1, you can test a realm using the realm s Testing tab in the WebLogic Console. Rather than trying to describe everything you need to do to back out from a bad realm configuration, we recommend that in addition to testing your realm you make a backup of the entire domain directory tree just before activating the new realm. This way, you can revert by simply restoring the entire domain directory and restarting the server.
Before we go on to talk about the RealmAdapter , we should tell you that the security framework has some undocumented debugging flags that will allow you to see what is happening with particular providers. You need to add these flags directly to your server s ServerDebug element in the config.xml file:
<ServerDebug Name=myserver DebugSecurityAtn=true DebugEmbeddedLDAP=true DebugSecurityAtz=true DebugSecurityRoleMap=true DebugSecurityAdjudicator=true DebugSecurityAuditor=true />
As with any manual changes to config.xml , always make sure that the admin server is shut down and that you make a backup copy of the config.xml in case you get into trouble while trying to edit it.
| Tip | Use the ServerDebug flags to help debug security provider issues. |
Using Compatibility Mode with the RealmAdapter
If you take a typical WebLogic Server 6.x config.xml and use it to start a WebLogic Server 7.0 or newer server, the server will automatically convert the config.xml over to the new security framework. This conversion process, however, will create a Compatibility Realm , using the RealmAdapter to run in compatibility mode. Using the automatic conversion capability is a very elegant way to get started with newer versions of WebLogic Server using your old 6.x security realm. Make sure that you use a copy of the 6.x config.xml file because this process does not create a backup of the original config.xml file. Because the filerealm.properties file contains a keyed and salted hash of the passwords, you will need to copy the SerializedSystemIni.dat file, along with the config.xml and filerealm.properties files.
This conversion process will set up realm adapters for all the pertinent security providers. It will allow you to continue using the various features of the WebLogic Server 6.1 security model. For example, the LDAPRealm ( v1 and v2 ), the NTRealm , the RDBMSRealm , and the UnixRealm are supported through this model. If the WebLogic Server 6.x config.xml file contains references to CertAuthenticator , you must manually add another authentication provider to use it. Simply go to Security- > Realms- > CompatibilityRealm- > Providers- > Authentication Providers- > RealmAdapterAuthenticator s General tab and add X.509 to the list of Chosen Types . If you happen to be using WebLogic Server 7.0, accomplishing this is a little less obvious. You need to add a new line in the Active Types text box that simply says X.509 . Once you apply the changes and restart the server, the RealmAdapter will be active and will use the CertAuthenticator to map X.509 certificates to a WebLogic Server user.
EAN: 2147483647
Pages: 125