Like identity assertion providers support specific types of tokens, principal validation providers support specific types of principals. For example, the WebLogic Principal Validation provider (described in Do You Need to Develop a Custom Principal Validation Provider?) signs and verifies the authenticity of WebLogic Server principals.

The principal validation provider that is associated with the configured authentication provider (as described in How Principal Validation Providers Differ From Other Types of Security Providers) will sign and verify all the principals stored in the subject that are of the type the principal validation provider is designed to support.

A principal validation provider is a special type of security provider that primarily acts as a helper to an authentication provider. The main function of a principal validation provider is to prevent malicious individuals from tampering with the principals stored in a subject.

The AuthenticationProvider SSPI (as described in Implement the AuthenticationProviderV2 SSPI) includes a method called getPrincipalValidator. In this method, you specify the principal validation provider's runtime class to be used with the authentication provider. The principal validation provider's runtime class can be the one Oracle provides (called the WebLogic Principal Validation provider) or one you develop (called a custom principal validation provider). An example of using the WebLogic Principal Validation provider in an authentication provider's getPrincipalValidator method is shown in Figure 3-1.

You do not generate MBean types for principal validation providers. Instead, specify a principal validator from the authentication provider.

When the WebLogic Security Framework attempts an authentication (or authorization) operation, it checks the subject's principals to see if they are valid. If a principal is not valid, the WebLogic Security Framework throws a security exception with text indicating that the subject is invalid. A subject may be invalid because:

• A principal in the subject does not have a corresponding principal validation provider configured (which means there is no way for the WebLogic Security Framework to validate the subject).

  Note:

  Because you can have multiple principals in a subject, each stored by the LoginModule of a different authentication provider, the principals can have different principal validation providers.

• A principal was signed in another WebLogic Server security domain (with a different credential from this security domain) and the caller is trying to use it in the current domain.

• A principal with an invalid signature was created as part of an attempt to compromise security.

• A subject never had its principals signed.

If you have simple user and group principals (that is, they only have a name), and you want to use the WebLogic Principal Validation provider:

• Use the existing weblogic.security.principal.WLSUserImpl and weblogic.security.principal.WLSGroupImpl classes. See the WLSUser and WLSGroup interfaces in the weblogic.security.spi package for usage information.

• Use the weblogic.security.provider.PrincipalValidatorImpl class. See the PrincipalValidator SSPI for usage information.

If you have user or group principals with extra data members (that is, in addition to a name), and you want to use the WebLogic Principal Validation provider:

• Write your own UserImpl and GroupImpl classes.

• Extend the weblogic.security.principal.WLSAbstractPrincipal class.

• Implement the weblogic.security.spi.WLSUser and weblogic.security.spi.WLSGroup interfaces.

• Implement the equals() method to include your extra data members. Your implementation should call the super.equals() method when complete so the WLSAbstractPrincipal can validate the remaining data.

  Note:

  By default, only the user or group name will be validated. If you want to validate your extra data members as well, then implement the getSignedData() method.

• Use the weblogic.security.provider.PrincipalValidatorImpl class. See the PrincipalValidator SSPI for usage information.

If you have your own validation scheme and do not want to use the WebLogic Principal Validation provider, or if you want to provide validation for principals other than WebLogic Server principals, then you need to develop a custom principal validation provider.

To implement the PrincipalValidator SSPI, provide implementations for the following methods:

• validate

  public boolean validate(Principal principal) throws SecurityException;
  

  The validate method takes a principal as an argument and attempts to validate it. In other words, this method verifies that the principal was not altered since it was signed.

• sign

  public boolean sign(Principal principal);
  

  The sign method takes a principal as an argument and signs it to assure trust. This allows the principal to later be verified using the validate method.

  Your implementation of the sign method should be a secret algorithm that malicious individuals cannot easily recreate. You can include that algorithm within the sign method itself, have the sign method call out to a server for a token it should use to sign the principal, or implement some other way of signing the principal.

• getPrincipalBaseClass

  public Class getPrincipalBaseClass();
  

  The getPrincipalBaseClass method returns the base class of principals that this principal validation provider knows how to validate and sign.

See Java API Reference for Oracle WebLogic Server for the PrincipalValidator SSPI.