To access a Jakarta EE application, users must be authenticated against the identity store in cases where the identity store is any of the following:

• A single LDAP store.

• Several LDAP stores of the same kind.

• Several LDAP stores of different kinds, such as, for example Microsoft Active Directory and Oracle Internet Directory.

• A single DB store.

• Several LDAP and DB stores.

This use case requires:

• Allowing access to the application to only authenticated users.

• Not modifying the application code, even when customers have user identities in different repositories.

This use case features:

• Configuring the appropriate authentication providers according to your particular set of user repositories.

• Configuring the authentication provider in case of a mixed LDAP or mixed LDAP and DB types.

According to the repository used, the details of this use case are divided into the following scenarios:

• Single user repository - Configure the appropriate WebLogic Server Authentication Provider.

• Multiple user repositories - Configure the LDAP providers.

• DB repositories - Configure the database providers.

For information about authentication providers, see WebLogic Server Authentication Providers.

A Jakarta EE application not using deployment descriptors must authenticate the user programmatically against the configured identity store(s).

This use case requires using OPSS APIs to authenticate a user, and it features:

• Configuring authentication providers for a Java container

• Using the oracle.security.jps.service.login.LoginService interface to authenticate the user.

For information about authentication, see About Authentication in Jakarta EE Applications.

A Java SE application must authenticate users against the LDAP identity store used in the domain. The application code requesting authentication must be the same regardless of the specifics of the domain's identity store.

This use case requires configuring the identity store(s) against which the authentication should take place and using the oracle.security.jps.service.login.LoginService interface. A Java SE application can use only one identity login module.

For information about using login modules programmatically, see Using the Login Modules in Java SE Applications.

An application that can run in two different environments requires access to user profile information stored in an LDAP store. The LDAP server may differ with the environment.

More specifically, this use case assumes that:

• The application uses the UserProfile.getEmail method.

• In one environment, mail is configured in the Microsoft Active Directory server:

  mail.attr = msad_email
  

• In the other environment, mail is configured in the Oracle Identity Directory server:

  mail.attr = mail
  

For the application to retrieve the correct information without modifying the code and regardless of the environment (first or second) in which it runs, you must configure the identity store providers with the correct property in each of the environments.

In Microsoft Active Directory, set the identity store provider name property:

<property name="mail.attr" value="msad_mail">

In Oracle Identity Directory, set the identity store provider name property:

<property name="mail.attr" value="mail"

For information about identity store provider configuration, see Configuring the Identity Store Provider.

An application requires access to user profile information located in more than one LDAP store servers. In this scenario, you must configure the environment for multiple LDAP stores. For information about the procedure, see Configuring Single and Multiple LDAPs.

For a Jakarta EE application that allows access only to users that had been assigned specific roles in web descriptors, the group-to-role assignment must be configurable at deployment based on the customer's environment.

For information about declarative security, see the following topics in Developing Applications with the WebLogic Security Service:

• Using Declarative Security with Web Applications

• Using Declarative Security with EJBs

For an Oracle ADF application that requires fine-grained authorization at the level of individual controls on the pages of the application, you must externalize policies and customize them after you application deployment.

The application requires securing web services with fine-grained authorization. For information about Web services, see Configuring Authorization Using Oracle Web Services Manager in Securing Web Services and Managing Policies with Oracle Web Services Manager.

A Jakarta EE application requires codesource permissions to perform specific actions. Typical examples are reading a credential from the credential store or looking up policies. For information about permissions, see Configure a Grant.

A non-Oracle ADF application requires fine-grained authorization checks. In this scenario:

• Place checks in the application code

• Configure the appropriate policies

For information about managing and checking policies programmatically, see The JAAS/OPSS Authorization Model.

An application requires a credential to connect to a back-end system, such as a database or an LDAP server. The application code should reference this credential in such a way that the specifics of the credential can be changed per customer post deployment without modifying the application code. Furthermore, this use case also requires specifying who can access the credential store and what operations an authorized user can perform on credential data.

This use case features:

• Using the credential store to persist credentials

• Fetching credentials at runtime with the Credential Store Framework API in application code

• Defining and enforcing system policies on codesource

The settings explained in this use case apply to all applications and components in a domain. Applications running in a domain require recording when policies, credentials, or keys are changed, and the policies evaluated in a particular time interval.

This use case features:

• Integrating applications with Oracle Platform Security Services Common Audit Framework.

• Defining application audit categories and events in security areas, and making the application audit-aware.

• Setting the appropriate filter level in each application.

The settings explained in this use case apply to all applications and components in a domain. Applications must record business-related activity in the context of a functional flow. Specifically, the application requires logging the users and the business actions performed by them in a particular time interval.

To implement this scenario, you create audit events based on business needs, and the application logs the event activity in the audit store. In addition, you generate audit reports from audit events, manage runtime audit policies, and modify audit event definitions, as needed.

This use case features:

• Allowing applications to define business functional areas (as audit categories), business activities (as audit events in categories), and attributes in each category.

• Registering applications at deployment, updating audit definitions, and deregistering applications after deployment.

• Managing audit artifacts with Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control) or WebLogic Scripting Tool (WLST) commands.

A client application in a container requires propagating the executing user identity to a web service over the Simple Object Access Protocol (SOAP). The web service may be running in the same domain (same or different Managed Server), or in a different domain.

For information about OWSM, see Securing Web Services and Managing Policies with Oracle Web Services Manager.

A client application in container requires propagating a user identity (distinct from the executing user identity) to a web service over SOAP.

In this use case, the application gets the specific identity to propagate from the credential store and uses OWSM ability to propagate the identity to a remote server.

For information about OWSM, see Securing Web Services and Managing Policies with Oracle Web Services Manager.

A client application in container requires propagating a user identity (stored in the security store) to a different WebLogic Server domain.

For information about domain trust, see Enabling Trust Between WebLogic Server Domains in Administering Security for Oracle WebLogic Server.

A client application in container requires propagating identities over HTTP. The recommended implementation is to use the OPSS trust service.

An application requires a central repository of policies, credentials, audit configuration, trusts, and keys, and a set of tools to manage it. To implement this use case, use OPSS services and the tools to manage security services.

An application requires a custom tool to manage externalized security data. To implement this use case, create a custom graphical user interface that calls OPSS APIs to display and manage security data in a context meaningful to the application.

An application running in a domain (where several server instances may be distributed across multiple machines) requires propagating security data changes when you initiate changes on the Administration Server and data on Managed Servers is refreshed based on caching policies. Changes must take effect in all components of the application regardless of where they are running. To implement this use case, use the OPSS MBeans or OPSS APIs to modify security data.

On the client side (Domain1) where the token is generated:

• Develop the Client Application

• Configure the Truststore

• Add a TrustServiceAccessPermission Grant

• Configure the Provider

The client application can be a Java SE or Jakarta EE application. The following example illustrates the client application:

// Authentication type name
public static final String AUTH_TYPE_NAME = "OIT";
// The authenticated username
String user = "weblogic"; 
// URL of the target application
URL url = "http://<host>:<port>/<destinationApp>"; 
//-----------------------------------------
JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext jpsCtx = ctxFactory.getContext();
final TrustService trustService = jpsCtx.getServiceInstance(TrustService.class);
final TokenManager tokenMgr = trustService.getTokenManager();
final TokenContext ctx = tokenMgr.createTokenContext(
    TokenConfiguration.PROTOCOL_EMBEDDED);
UsernameToken ut = WSSTokenUtils.createUsernameToken("wsuid", user);
GenericToken gtok = new GenericToken(ut);
ctx.setSecurityToken(gtok);
ctx.setTokenType(SAML2URI.ns_saml);
Map<String, Object> ctxProperties = ctx.getOtherProperties();
ctxProperties.put(TokenConstants.CONFIRMATION_METHOD,
    SAML2URI.confirmation_method_bearer);
 
AccessController.doPrivileged(new PrivilegedAction<String>() {
    public String run() {
        try {
            tokenMgr.issueToken(ctx);
        } catch (Exception e) {        
            e.printStackTrace();
        }
        return null;
    }
});
 
Token token = ctx.getSecurityToken();
String b64Tok = TokenUtil.encodeToken(token);
 
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setDoOutput(true);
connection.setReadTimeout(10000);
connection.setRequestProperty("Authorization", AUTH_TYPE_NAME + " " + b64Tok);
connection.connect();
BufferedReader rd = new BufferedReader(new InputStreamReader(
    connection.getInputStream()));
StringBuilder sb = new StringBuilder();
 
String line = null;
while ((line = rd.readLine()) != null) {
    sb.append(line);
}
connection.disconnect();	
System.out.println(sb.toString());

The truststore should be provisioned with a client certificate and a private key. The certificate is exported from the keystore and imported into the truststore. Both the keystore and the truststore, are managed by the keystore service (KSS) keystore in the client domain.

The following script illustrates these tasks:

# Update following values with correct value
user = "<username>"
password = "<password>"
wlsurl = "t3(s)://<host>:<port>"
stripeName = "<stripeNmae>"
 
#-----------------------------------------------
ksName = "<trustservice_ks>"
tsName = "<trustservice_ts>"
aliasName = "<trustservice>"
issuerDN = "cn=" + aliasName
 
print "Stripe Name: " + stripeName
 
print "KeyStore Name: " + ksName
print "TrustStore Name: " + tsName
print "Alias Name: " + aliasName
print "Issuer DN: " + issuerDN
 
#-----------------------------------------------
connect(user, password, wlsurl)
 
svc = getOpssService(name='KeyStoreService')
svc.listKeyStores(appStripe=stripeName)

svc.createKeyStore(appStripe=stripeName, name=ksName, password="", permission=true)
svc.generateKeyPair(appStripe=stripeName, name=ksName, password="", dn=issuerDN, keysize="1024", alias=aliasName, keypassword="", algorithm="RSA")
svc.exportKeyStoreCertificate(appStripe=stripeName, name=ksName, password="", alias=aliasName, keypassword="", type="Certificate", filepath="./trustservice.cer")
 
svc.createKeyStore(appStripe=stripeName, name=tsName, password="", permission=true)
svc.importKeyStoreCertificate(appStripe=stripeName, name=tsName, password="", alias=aliasName, keypassword="", type="TrustedCertificate", filepath="./trustservice.cer")
 
svc.listKeyStores(appStripe=stripeName)
svc.listKeyStoreAliases(appStripe=stripeName, name=ksName, password="", type="Certificate")
exit()

The following grant (in the application jazn-data.xml file) illustrates a codesource permission that allows clients to use trust methods:

<grant>
  <grantee>
    <codesource> 
       <url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
    </codesource>
  </grantee>
  <permissions>
    <permission> 
       <class>oracle.security.jps.service.trust.TrustServiceAccessPermission</class>
      <name>appId=*</name>
      <actions>issue</actions>
    </permission>
  </permissions>
</grant>

Add this grant to the security store with the grantPermission WLST command, or if the application is a Jakarta EE application and the jazn-data.xml file is packed with the application, then have the grant migrated to the security store at application deployment.

The following example illustrates trust provider properties:

<propertySet name="trust.provider.embedded">
	<property name="trust.keystoreType" value="KSS"/>
  <property name="trust.keyStoreName" value="kss://<stripeName>/<keystoreName>"/>
  <property name="trust.trustStoreName" value="kss://<stripeName>/<truststoreName>"/>
  <property name="trust.aliasName" value="<aliasName>"/>
  <property name="trust.issuerName" value="<issuerName>"/>
  <property name="trust.provider.className" value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
  <property name="trust.clockSkew" value="60"/>
  <property name="trust.token.validityPeriod" value="1800"/>
  <property name="trust.token.includeCertificate" value="false"/>
</propertySet>

On the server side (Domain2) where the token is validated:

• Develop the Server Application

• Configure web.xml

• Configure the Asserter

• Provision the Keystore

• Add Permissions

• Configure the Provider

The Java servlet code first obtains the asserted user:

public void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
   String username = request.getRemoteUser();
   ServletOutputStream out = response.getOutputStream();
   out.print("Asserted username: " + username);
   out.close();
}

Set the login configuration method to CLIENT-CERT in the web.xml file:

<web-app id="WebApp_ID"
…
 <login-config>
   <auth-method>CLIENT-CERT</auth-method>
   <realm-name>Identity Assertion </realm-name>
 </login-config>
…
</web-app>

Configure the asserter in one of the following ways:

• Log in as an administrator and navigate to Security Data Tree > Realms > myrealm > Authentication Providers. Click the Authentication Providers drop-down, select Authentication Provider Configurations - Edit Tree and then choose TrustServiceIdentityAsserter.

  This asserter calls trust methods to decode and validate the token from the incoming request, and passes the user name to WebLogic Server to establish the asserted subject.

• Use a script like the following:

  connect("<username>","<password>","t3://<host>:<port>")
  edit()
  startEdit()
  realm = cmo.getSecurityConfiguration().getDefaultRealm()
  tsia = realm.lookupAuthenticationProvider("TSIA")
  if tsia != None:
      realm.destroyAuthenticationProvider(tsia)
  tsia = realm.createAuthenticationProvider("TSIA", "oracle.security.jps.wls.providers.trust.TrustServiceIdentityAsserter")
  save()
  activate()
  disconnect()

Export the client certificate you provisioned in the Domain1's keystore and import it into the Domain2's truststore, as illustrated in the following example.

# Update following values with correct value
user = "<username>"
password = "<password>"
wlsurl = "t3(s)://<host>:<port>"
stripeName = "<stripeName>"
ksName = "<trustservice_ks>"
tsName = "<trustservice_ts>"
aliasName = "<trustservice>"
print "Importing certificate for : " + aliasName
print "Stripe Name: " + stripeName
print "TrustStore Name: " + tsName
print "Alias Name: " + aliasName
connect(user, password, wlsurl)
svc = getOpssService(name='KeyStoreService')
svc.listKeyStores(appStripe=stripeName)

# switch Trust service to using KSS
svc.createKeyStore(appStripe=stripeName, name=tsName, password="", permission=true)
svc.importKeyStoreCertificate(appStripe=stripeName, name=tsName, password="", alias=aliasName, keypassword="", type="TrustedCertificate", filepath="./trustservice.cer")
svc.listKeyStoreAliases(appStripe=stripeName, name=tsName, password="", type="TrustedCertificate")
exit()

Use the grantPermission WLST command to add codesource grants to the application's jazn-data.xml file.

For example, the following codesource grant is required for the MyApp application to use trust methods:

<grant>
  <grantee
    <codesource> 
      <url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
    </codesource>
  </grantee>
  <permissions>
    <permission> 
     <class>oracle.security.jps.service.trust.TrustServiceAccessPermission</class>
      <name>appId=*</name>
      <actions>validate</actions>
    </permission>
  </permissions>
</grant>

The following example illustrates trust provider properties:

<propertySet name="trust.provider.embedded">
	<property name="trust.keystoreType" value="KSS"/>
  <property name="trust.keyStoreName" value="kss://<stripeName>/<keystoreName>"/>
  <property name="trust.trustStoreName" value="kss://<stripeName>/<truststoreName>"/>
  <property name="trust.aliasName" value="<aliasName>"/>
  <property name="trust.issuerName" value="<issuerName>"/>
  <property name="trust.provider.className" value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
  <property name="trust.clockSkew" value="60"/>
  <property name="trust.token.validityPeriod" value="1800"/>
  <property name="trust.token.includeCertificate" value="false"/>
</propertySet>

If the provider is used only for token validation, then the aliasName and issuerName attributes are not used for token validation and are therefore optional. In this case to validate a token, the provider looks for the certificate using the name included in the token.