AIA 11g PIP security policy with SOAP UI

With AIA PIP installation, you see basically three policy installed out of the box and there are lot of global policy set configured using these policies and attached to Provider, Requester or Adapter services.

Server side policies

1. oracle/aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON 

If service is configured with this policy, then client needs to provide one of three security measures:

• SAML
• WSSE Username Token
• HTTP basic authentication

2. oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON

If service is configured with this policy, then client needs to provide one of the two security measures:

• SAML
• WSSE Username Token

Client Side Policies

oracle/aia_wss10_saml_token_client_policy_OPT_ON

This is client side policy and it can be configured for any web service or composite which is protected via AIA server side policies.



Testing Service Side Policies using SOAP UI (or any other WS testing client)

1. oracle/aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON 

• WSSE Username Token

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
               xmlns:sam="http://xmlns.oracle.com/SAMLProject/SAMLProcess2/SAMLBPELProcess2">
   <soapenv:Header>
      <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken>
            <wsse:Username>weblogic</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">*******</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <sam:process>
         <sam:input>asdf</sam:input>
      </sam:process>
   </soapenv:Body>
</soapenv:Envelope>

• HTTP basic authentication

2. oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON

• WSSE Username Token

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
               xmlns:sam="http://xmlns.oracle.com/SAMLProject/SAMLProcess2/SAMLBPELProcess2">
   <soapenv:Header>
      <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken>
            <wsse:Username>weblogic</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">*******</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <sam:process>
         <sam:input>asdf</sam:input>
      </sam:process>
   </soapenv:Body>
</soapenv:Envelope>

Weblogic Custom Authentication Provider #2

I wrote in previous blog entry about how to configure custom authentication provider with Weblogic server. However, there are quite a few concerns associated with this approach, so I had to write generic custom authentication provider, and then I can plugin any module I like.

Some of the concerns with out of the box approches

• Need to implement both WLS and JPS identity 
•  WLS security is used for all basic Weblogic Modules (e.g. Console, EM, etc.)
• JPS security provider is used for SOA modules (e.g. Worklist application)
• WLS custom security provider is relatively easy to write - details
• JPS custom security provider is really lot of work as it requires you to implement multiple interfaces (similar to 10g custom identity service) and multiple methods details
• Need to register different security provider at different places

Implemented Solution

I believe at the end if would be much easier to if all the complex details can be hidden regarding WebLogic and SOA security provider and if client has to just implement a simple interface and provide that in the class path that would be ideal way to go. So here it goes:

Install Java Custom Security Provider

1. download CustomSecurityProvider.jar
2. Copy this jar file to $wls_server_home/server/lib/mbeantypes and $domain_home/lib directories
3. Modify file : $domain_home/config/fmwconfig/jps-config.xml
• Add Following  

<serviceProvider type="IDENTITY_STORE" name="custom.provider" class="oracle.security.jps.internal.idstore.generic.GenericIdentityStoreProvider">
    <description>Custom IdStore Provider</description>
</serviceProvider>

<serviceInstance name="idstore.custom" provider="custom.provider"  location="./">
    <description>Custom Identity Store Service Instance</description>
    <property name="idstore.type" value="CUSTOM"/>
    <property name="ADF_IM_FACTORY_CLASS" value="com.spring.security.jps.identity.CustomIdentityStoreFactory"/>
    <property name="CustomSecurityProviderPlugIn" value="com.spring.security.plugin.CustomSecurityProviderPlugin"/>
</serviceInstance>

• Replace Following

<jpsContext name="default">
    <serviceInstanceRef ref="credstore"/>
    <serviceInstanceRef ref="keystore"/> 
    <serviceInstanceRef ref="policystore.xml"/>
    <serviceInstanceRef ref="audit"/>
    <!--
        <serviceInstanceRef ref="idstore.ldap"/>
        <serviceInstanceRef ref="trust"/>
        <serviceInstanceRef ref="pdp.service"/>
        <serviceInstanceRef ref="attribute"/>
    -->
    <serviceInstanceRef ref="idstore.custom"/>
</jpsContext>

4. Restart Admin and Managed servers

Configure Java Custom Security Provider

• Implement the custom java security provider interface: com.spring.security.plugin.ICustomSecurityProviderPlugIn 
• Note that for given custom repository we only need to implement following methods

package com.spring.security.plugin;

import java.util.List;
import java.util.Map;
import java.util.Properties;

public interface ICustomSecurityProviderPlugIn {
    
     /* WLS */ 
    void initialize(Properties properties);
    boolean login(String userName, java.lang.String password);
    List<String> getUserRoles(java.lang.String userName);

     /* JPS */ 
    List<Map> searchUsers(String userNamePattern);
    List<Map> searchRoles(String roleNamePattern);
    Map getUserDetail(String userName);
    Map getRoleDetail(String roleName);
}

• If you opt to implement WLS, you can ignore to implement JPS related methods
• A sample implementation is provided with jar file (com.spring.security.plugin.CustomSecurityProviderPlugIn)

Make your implemented java or jar class available to weblogic classpath ($domain_home/lib)

Custom Security Provider should be available in drop down as below

Modify file : $domain_home/config/fmwconfig/jps-config.xml with your implementation

<serviceInstance name="idstore.custom" provider="custom.provider"  location="./">
    <description>Custom Identity Store Service Instance</description>
    <property name="idstore.type" value="CUSTOM"/>
    <property name="ADF_IM_FACTORY_CLASS" value="com.spring.security.jps.identity.CustomIdentityStoreFactory"/>
    <property name="CustomSecurityProviderPlugIn" value="com.spring.security.plugin.CustomSecurityProviderPlugin"/>
</serviceInstance>

Restart the server

Weblogic Custom Authentication #1

We can configure multiple WLS authentication provider (e.g. ActiveDirectory, Sun LDAP) as shown below.

If authentication and authorization information is stored custom repository not supported by above list, we can use following option.

CustomDBMSAuthenticator : Once it is configured as below, you can plugin in any Java class as long as it implements weblogic.security.providers.authentication.CustomDBMSAuthenticatorPlugin interface.

We can see the method "lookupPassword" which is called during authentication.

package weblogic.security.providers.authentication;
public interface CustomDBMSAuthenticatorPlugin {
    void initialize(weblogic.management.security.ProviderMBean providerMBean) { }
    void shutdown() { }
    java.lang.String lookupPassword(java.sql.Connection connection, java.lang.String userName) { }
    boolean userExists(java.sql.Connection connection, java.lang.String userName) { }
    java.lang.String[] lookupUserGroups(java.sql.Connection connection, java.lang.String userName) { }
}

We can completely ignore connection information and write custom java code to reach out to any custom repository and return the password. In that way it can be used for any custom repository instead of just custom database repository.

The major concern with this interface is that it requires you to return the password in lookupPassword method. Majority of the time enterprise level identity repository is not going to give you the password. Enterprise custom repository usually have their own authenticate method but above interface doesn't provide the password.

Another concern is that it only support WLS authentication and authorization. It doesn't provide JPS authentication and authorization.

• WLS authentication is used for all basic WLS modules (e.g. Console, EM, etc.)
• JPS authentication is used for SOA specific component, especially Worklist Application. 

If we implement custom authentication provider using above approach, it only covers WLS authentication and authorization, it would not be called during SOA module login (e.g. Worklist App).