Authentication Configuration  Locate

This section explains how to change the Oracle Service Registry configuration to allow the following authentication options:

HTTP Basic  Locate

[Important]Important

In the case where Registry is deployed to an Oracle WebLogic Server

  • Add the <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> element to config.xml in the directory [domain]\config within the <security-configuration> element.

  • The enforce-valid-basic-auth-credentials flag effects the entire domain. Client requests that use HTTP BASIC authentication will be ignored by WebLogic Server authentication.

To allow HTTP Basic authentication:

  1. Modify REGISTRY_HOME/app/uddi/services/Wasp-inf/package.xml to enable HTTP basic authentication as follows:

    1. Under <processing name="UDDIv1v2v3PublishingProcessing"/>, uncomment <use ref="tns:HttpBasicInterceptor"/>. This enables the HTTP Basic authentication for UDDI Publishing API v1, v2, v3.

    2. Under <processing name="UDDIv1v2v3InquiryProcessing">, add <use ref="tns:HttpBasicInterceptor"/> . This enables the HTTP Basic authentication for all three versions of the UDDI Inquiry API.

    3. Under <processing name="wsdl2uddiProcessing">, add <use ref="tns:HttpBasicInterceptor"/> . This enables the HTTP Basic authentication for versions 2 and 3 of the WSDL2UDDI API.

    4. Add the attribute accepting-security-providers="HttpBasic" to other service-endpoints (except UDDI publishing and Inquiry endpoint) you wish to access via HTTP Basic authentication.

    A fragment of the package.xml is shown in Example 2

  2. Shutdown Oracle Service Registry, delete the REGISTRY_HOME/work directory, and restart the registry.

Example 2. package.xml - HTTP Basic Enabled

.....
    <service-endpoint path="/inquiry" version="3.0" name="UDDIInquiryV3Endpoint" 
        service-instance="tns:UDDIInquiryV3" processing="tns:UDDIv1v2v3InquiryProcessing"
          accepting-security-providers="HttpBasic">
        <wsdl uri="uddi_api_v3.wsdl" service="uddi_api_v3:UDDI_Inquiry_SoapService"/>
        <envelopePrefix xmlns="arbitraryNamespace" value=""/>
        <namespaceOptimization xmlns="arbitraryNamespace">false</namespaceOptimization>
    </service-endpoint>
    <service-instance 
        implementation-class="com.systinet.uddi.publishing.v3.PublishingApiImpl" 
        name="UDDIPublishingV3"/>
    <service-endpoint path="/publishing" version="3.0" name="UDDIPublishingV3Endpoint" 
        service-instance="tns:UDDIPublishingV3" 
        processing="tns:UDDIv1v2v3PublishingProcessing" 
        accepting-security-providers="HttpBasic">
        <wsdl uri="uddi_api_v3.wsdl" service="uddi_api_v3:UDDI_Publication_SoapService"/>
        <envelopePrefix xmlns="arbitraryNamespace" value=""/>
        <namespaceOptimization xmlns="arbitraryNamespace">false</namespaceOptimization>
    </service-endpoint>

    <processing name="UDDIv3Processing">
      <use ref="uddiclient_v3:UDDIClientProcessing"/>
      <fault-serialization name="MessageTooLargeFaultSerializer" 
      serializer-class="com.systinet.uddi.publishing.v3.serialization.MessageTooLargeFaultSerializer" 
      serialized-exception-class="com.systinet.uddi.interceptor.wasp.MessageTooLargeException"/>
    </processing>

    <processing name="UDDIv1v2v3PublishingProcessing">
     <use ref="uddiclient_v3:UDDIClientProcessing"/>
     <use ref="uddiclient_v2:UDDIClientProcessing"/>
     <use ref="uddiclient_v1:UDDIClientProcessing"/>
     <!-- HttpBasic (without authtoken)         --> 
     <use ref="tns:HttpBasicInterceptor"/>        

    <interceptor name="MessageSizeCheckerInterceptor" 
       implementation-class="com.systinet.uddi.interceptor.wasp.MessageSizeCheckerInterceptor" 
       direction="in">
        <config:maxMessageSize>2097152</config:maxMessageSize>
        </interceptor>
    </processing>

    <processing name="UDDIv1v2v3InquiryProcessing">
        <use ref="tns:UDDIv3Processing"/>
        <use ref="tns:UDDIv2Processing"/>
        <use ref="tns:UDDIv1Processing"/>
        <use ref="tns:HttpBasicInterceptor"/>        
    </processing>
.....

Netegrity SiteMinder  Locate

To allow Netegrity SiteMinder authentication:

  1. Modify REGISTRY_HOME/app/uddi/services/Wasp-inf/package.xml as follows:

    1. Under <processing name="UDDIv1v2v3PublishingProcessing"/>, add <use ref="tns:SiteMinderInterceptor"/>. This enables the SiteMinder authentication for all three versions of the UDDI Publishing API.

    2. Under <processing name="UDDIv1v2v3InquiryProcessing">, add <use ref="tns:SiteMinderInterceptor"/>. This enables the SiteMinder authentication for versions 1, 2, and 3 of the Inquiry API.

    3. Under <processing name="wsdl2uddiProcessing">, add <use ref="tns:SiteMinderInterceptor"/> . This enables the SiteMinder authentication for versions 2 and 3 of the WSDL2UDDI API.

    4. Add the attribute accepting-security-providers="Siteminder" to other service-endpoints (except UDDI publishing and Inquiry endpoint) you wish to access via Netegrity SiteMinder authentication.

    5. Under the elements <securityProviderPreferences> and <interceptor name="SiteMinderInterceptor", fill in:

      • <loginNameHeader> - login name header

      • <groupHeader> - group header

      • <delimiter> - group name delimiter.

      [Important]Important

      You must set the same element values to both <securityProviderPreferences> and <interceptor name="SiteMinderInterceptor" elements.

    A fragment of the package.xml is shown in Example 3

  2. Shutdown Oracle Service Registry, delete the REGISTRY_HOME/work directory, and restart the registry.

Example 3. package.xml - Netegrity SiteMinder Enabled

.....
  <!-- Netegrity SiteMinded security provider preferences for the server side -->
    <securityProviderPreferences xmlns="http://systinet.com/wasp/package/extension" 
       name="Siteminder">
        <loginNameHeader>sm-userdn</loginNameHeader>
        <groupHeader>sm-role</groupHeader>
        <delimiter>^</delimiter>
    </securityProviderPreferences>

    <!-- Netegrity SiteMinded interceptor-->
    <interceptor name="SiteMinderInterceptor" 
         implementation-class="com.systinet.uddi.security.siteminder.SmInterceptor" >
        <config:loginNameHeader>sm-userdn</config:loginNameHeader>
        <config:groupHeader>sm-role</config:groupHeader>
        <config:delimiter>^</config:delimiter>
    </interceptor>
.....

SSL Client authentication with Embedded HTTP/HTTPS Server  Locate

Oracle Service Registry used with Embedded HTTP/HTTPS Server can be configured to perform authentication using client certificate obtained via 2-way SSL, where the client must also authenticate itself to a server. Setup instructions are different for an embedded HTTP/HTTPS server and a registry deployed to an application server. This section is focused on Embedded HTTP/HTTPS Server onlys, see J2EE Server Authentication for instruction of how to configure SSL client authentication for deployed registry.

To allow SSL client authentication for a standalone registry:

  1. Make sure that the registry is not running.

  2. Modify REGISTRY_HOME/conf/serverconf.xml as follows:

    • Under <httpsPreferences name="https">, change <needsClientAuth> to true. This configures HTTPS transport to require client certificates.

    • Under <securityPreferences name="main">, add <acceptingSecurityProvider>SSL</acceptingSecurityProvider>. This ensures the mapping of client certificates to a user name.

    A fragment of changed REGISTRY_HOME/conf/serverconf.xml is shown in Example 4.

  3. Trust the certificate of a certification authority that is used to issue client certificates. Run the PStoreTool tool from the REGISTRY_HOME/bin directory to import this certificate to a truststore that is used by registry.

                      PStoreTool add -certFile <client certificates authority certificate file> -config <path to pstore.xml>
                    
  4. Configure how a client certificate is mapped to a user name. Registry comes with JAAS login module that extracts the user name out of a subject that is necessary part of a client certificate. The login module that performs this mapping is configured under the CertsMapping entry of the REGISTRY_HOME/conf/jaas.conf file. An example of CertsMapping entry is shown in Example 5.

    You can configure the following options:

    • debug - if set to true, debug actions of the login module are printed to an error stream. False by default.

    • issuer - issuer name. If set, mapped certificate must be issued by a certification authority with this subject name (recommended).

    • pattern - regular expression (as per java.util.regexp) that is used to get user names. The first capturing group of a specified pattern is used as a user name. When there is no capturing group and the pattern matches, the whole subject becomes a user name. Used regular expressions are case-insensitive. Examples are:

      • The default is (?<!\\,\s?)EMAILADDRESS=(.+)@. It matches a name listed in EMAILADDRESS. This regular expression ignores the case of EMAILADDRESS possibly contained in another part of subject.

      • CN=([^,]+) matches common name.

      • .* matches every subject. Since it has no capturing group, the whole subject DN is used.

    You can configure more than one login module to perform certificate mapping. This is useful when you have to accept different issuers and/or provide a fallback to a failed certificate mapping of the first configured login module. An example of a CertsMapping entry that allows the mapping of certificates issued by 2 issuers with different mappings is shown in Example 6.

  5. The registry is now configured for SSL client authentication. You may also change the applicability of SSL client authentication by changing the configuration of SSL security providers. This configuration is in the <securityProviderPreferences name="SSL"> element of the REGISTRY_HOME/conf/serverconf.xml file. An example is shown in Example 4.

Example 4. A fragment of serverconf.xml with 2-way SSL turned on

<?xml version="1.0" encoding="UTF-8"?>
<config name="main">
   ...
  <securityPreferences name="main">
     <!-- Added acceptingSecurityProvider -->
    <acceptingSecurityProvider>SSL</acceptingSecurityProvider>
    <pstoreInitParams/>
    ...
  </securityPreferences>
  ...
  <httpsPreferences name="https">
    ...
    <!-- Client authentication required -->
    <needsClientAuth>true</needsClientAuth>
    ...
  </httpsPreferences> 
  ...
  <!-- security provider preferences intended mainly for SSL client authentication -->
  <securityProviderPreferences name="SSL">
      <!-- What to do when SSL is not used to access the resource? Avalaible options:
      redirect
        - perform HTTP redirect to associated HTTPS URL (302 Moved Temporarily)
      fail
        - return a message that informs to use HTTPS URL (400 Bad Request)
      skip
        - do not perform certififate mapping at all
      perform
        - try to perform certificate mapping with no client certificates
      -->
      <whenNotSsl>skip</whenNotSsl>
      <!-- Can certificate mapping fail? If set to true and it fails, no received subject will be constructed. -->
      <certMappingMayFail>false</certMappingMayFail>
      <!-- Can a default account be created when no account for a mapped user exists? -->
      <createDefaultAccount>false</createDefaultAccount>
  </securityProviderPreferences>
</config>

Example 5. CertsMapping JAAS configuration

CertsMapping{
 com.systinet.uddi.security.jaas.CertMappingLoginModule sufficient pattern="(?<!\\,\s?)EMAILADDRESS=(.+)@" debug=false issuer="CN=Company CA, OU=mycomp";
};

Example 6. CertsMapping JAAS configuration with 2 possible issuers

CertsMapping{
 com.systinet.uddi.security.jaas.CertMappingLoginModule sufficient pattern="(?<!\\,\s?)EMAILADDRESS=(.+)@" debug=false issuer="CN=Company CA, OU=mycomp";
 com.systinet.uddi.security.jaas.CertMappingLoginModule sufficient pattern="CN=([^,]*)" issuer="CN=Company CA2, OU=mycomp" debug=false;
};

SSL Client Authentication in Oracle WebLogic  Locate

This section described how to enable SSL and SSL Client Authentication in Oracle Service Registry deployed to Oracle WebLogic Server 10.3. The following steps assume that Registry is already deployed to WebLogic.

  1. Locate WEB-INF/web.xml for the WAR file that is used. You may either edit the WAR file with a file commander that allows you to edit such archives directly and redeploy it later or locate this file where the WAR file is unpacked.

    1. Add tags inside <web-app>:

                                 <context-param>
                                      <param-name>use.request.user</param-name>
                                      <param-value>true</param-value>
                                  </context-param>
      
                                  <login-config>
                                    <auth-method>CLIENT-CERT</auth-method>
                                  </login-config>
      
                                  <security-constraint>
                                    <display-name>HTTPS required to access registry</display-name>
                                    <web-resource-collection>
                                      <web-resource-name>Protected Area</web-resource-name>
                                      <url-pattern>/*</url-pattern>
                                      <http-method>DELETE</http-method>
                                      <http-method>GET</http-method>
                                      <http-method>POST</http-method>
                                      <http-method>PUT</http-method>
                                    </web-resource-collection>
                                    <user-data-constraint>
                                      <description>Require confidentiality</description>
                                      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
                                    </user-data-constraint>
                                  </security-constraint>
                                       

    2. Change servlet class to look like this: <servlet-class>com.systinet.transport.servlet.server.registry.RegistryServlet</servlet-class>

  2. Start Registry in WebLogic. The Registry still works with normal user/password authentication.

  3. Select Environment/Servers/_your_server_/Configuration/

    1. Select the Keystores Tab. Select Custom Identity and Custom Trust". Provide values to your identity and trust stores. Click Save.

    2. Select the SSL Tab. Click the Advanced option. Fill in Identity Alias and Password. Select Client Certs Requested and enforced in Two Way Client Cert Behavior. Click Save.

  4. Click Security Realms in Domain Structure. Select myrealm.

    1. Click Users and groups. Create a new user called "admin". You can create other users here too. Their names are matched with the name part of emails in the certificate.

    2. Click the Providers tab. Create a new authentication provider. Name it "mysslauthprovider" and select DefaultIdentityAsserter. Click on the provider properties. Add the X.509 type. Click Save. Click the Provider specific tab. Check Use Default User Name Mapper. Leave default value "@" for Default User Name Mapper Attribute Delimiter. Click Save.

    [Note]Note

    The last step may not work when another provider with DefaultIdentityAsserter is present. Either modify the old provider or delete the old and configure the new "mysslauthprovider".

J2EE Server Authentication  Locate

The registry can be configured to let a J2EE application server perform authentication. Unlike Netegrity SiteMinder and HTTP Basic, the authentication takes place for the whole registry application. To allow J2EE server authentication:

  1. Locate the EAR or WAR file produced by the installer. It is available in REGISTRY_HOME/conf/porting or in the application server when deployed. Note that in case of an EAR file the actual WAR file is contained in it. Both files can be opened as ZIP archives.

  2. Modify WEB-INF/web.xml file in the WAR file as follows:

    1. Change the value of context parameter use.request.user to true.

    2. Add a login-config element with a type of the chosen J2EE authentication. Example 7 shows a login config that turns on the CLIENT-CERT authentication method, which is used for SSL client authentication.

      You may also add a security-constraint element to specify a set of resources where confidentiality and/or integrity is required. Example 7 contains a security-constraint that requires confidential communication between client and server for all registry resources, which typically means to allowing only HTTPS for communication with registry.

    3. Configure a J2EE application server for the authentication method of your choice. For SSL client authentication, this typically means setting up HTTPS transport to require client certificates and to map client certificates to user names. Consult your J2EE application server documentation for details.

  3. Continue deployment of the modified war file.

Example 7. A fragment of web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app>
    <display-name>Registry</display-name>
...
    <context-param>
        <param-name>use.request.user</param-name>
        <param-value>true</param-value>
    </context-param>
....
<!-- Added CLIENT-CERT authentication method -->
    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
    </login-config>

<!-- Added security contraint that allow to access registry only via HTTPS -->
    <security-constraint>
      <display-name>HTTPS required to access registry</display-name>
      <web-resource-collection>
        <web-resource-name>Protected Area</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>DELETE</http-method>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
        <http-method>PUT</http-method>
      </web-resource-collection>
      <user-data-constraint>
        <description>Require confidentiality</description>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>
</web-app>

Internal SSL Client Authentication Mapping in J2EE  Locate

While J2EE application authentication can be configured in many ways, some configurations can be cumbersome on some application servers. Internal SSL client authentication mapping may be easier to configure for simple deployments.

Internal client authentication mapping offers the same options for configuration as CertMapper as described in SSL Client authentication with Embedded HTTP/HTTPS Server. Installation steps:

  1. Ensure that certificates are trusted by the J2EE server. Some servers have dedicated trust stores, while others use the cacerts java keystore file inside Java runtime. Add the certificate of the Certification Authority you are using to the server's trust store as a trusted certificate.

  2. Set up your J2EE server SSL. You usually need to provide the Java trust store file with the server identity. Configure the server SSL to use the trust store by specifying file, alias and store password.

  3. Set up your J2EE server to ask for or require Client Authentication.

  4. Edit web.xml inside the deployed registry.

    • Change tag servlet-class to contain com.systinet.transport.servlet.server.registry.RegistryServletTwoWaySSL.

    • Add the CLIENT-CERT authentication method (as described in Example 8).

    • Add context parameters. Set the context parameter "twowayssl.use_user" to value "true".

    • Set the context parameter "twowayssl.issuer" to the X.509 Issuer DN of certificates you want to allow.

    • You can set the context parameter "twowayssl.mapping" to a regular expression for matching parts of Subject DN (by default, it is set to the name part of the email address in the email field).

    • You can set the context parameter "twowayssl.debug" to "true" for run-time information about matching.

    All context parameters that you set correspond to parameters in SSL Client authentication with Embedded HTTP/HTTPS Server. For examples of these parameters, see Example 8.

Example 8. A fragment of web.xml

    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
    </login-config>

    <context-param>
      <param-name>twowayssl.use_user</param-name>
      <param-value>true</param-value>
    </context-param>
    <context-param>
      <param-name>twowayssl.issuer</param-name>
      <param-value>C=CZ, ST=Czech, L=Prague, O=Example company, OU=Security Team, CN=CA</param-value>
    </context-param>

Disabling Normal Authentication  Locate

After you implement a custom authentication mechanism, such as a client SSL certificate, you may want to disable normal authentication. Disable normal authentication by removing permission for the get_authToken UDDI API from the system#everyone group. (The get_authToken API has this permission by default.)

To remove permission for the get_authToken UDDI API from the system#everyone group:

  1. Log into the WEB UI using your administrative account and open the Management tab.

  2. Open the Permissions page.

  3. Select the Group radio button.

  4. Edit the group system#everyone and remove the following permissions (Permission type / Api name / Actions):

    • org.systinet.uddi.security.permission.ApiUserPermission / org.systinet.uddi.client.v3.UDDI_Security_PortType / get_authToken,

    • org.systinet.uddi.security.permission.ApiUserPermission / org.systinet.uddi.client.v2.Publish / get_authToken,

    • org.systinet.uddi.security.permission.ApiUserPermission / org.systinet.uddi.client.v1.PublishSoap / get_authToken.

[Note]Note

Remember that you cannot log in to WEB user interfaces with the normal login dialog after you disable normal authentication.

Consoles Configuration  Locate

In this section, we will show you how to configure authentication for both Registry Control and Business Service Control. The configuration of consoles is very similar to the configuration of other endpoints.

[Note]Referring to jar packages

The file path REGISTRY_HOME/app/uddi/web.jar/WASP-INF/package.xml means the /WASP-INF/package.xml inside the jar package REGISTRY_HOME/app/uddi/web.jar.

For the Registry Control, modify the file REGISTRY_HOME/app/uddi/web.jar/WASP-INF/package.xml with the following:

<service-endpoint path="/web" name="WebUIEndpoint1" 
     service-instance="tns:WebUI" type="raw" other-methods="get" 
     accepting-security-providers="HttpBasic"/>
<service-endpoint path="/web/*" name="WebUIEndpoint2" 
     service-instance="tns:WebUI" type="raw" other-methods="get" 
     accepting-security-providers="HttpBasic"/>
            

If you want to set Netegrity SiteMinder provider, use accepting-security-providers="Siteminder"

For the Business Service Control do the same in the file REGISTRY_HOME/app/uddi/bsc.jar/WASP-INF/package.xml

We just set authentication providers for both HTTP and HTTPS protocols. Now, we must specify which protocol consoles will be using for user authentication. The default registry configuration is to use HTTP for browsing and searching. HTTPS is used for publishing. To avoid displaying the login dialog twice, (for the first time when accessing via HTTP then the second time when accessing via HTTPS), modify the configuration to use only one protocol.

For the Registry Control, modify url and secureUrl elements in the file REGISTRY_HOME/app/uddi/conf/web.xml to have the same value:

<url>https://servername:8443/registry</url>
<secureUrl>https://servername:8443/registry</secureUrl>
 

For the Business Service Control, make the same change in the REGISTRY_HOME/app/uddi/bsc.jar/conf/web.xml file.

Outgoing Connections Protected with SSL Client Authentication  Locate

Oracle Service Registry can be the client in SSL Client Authentication. This allows the following scenarios:

  • SOAP Client - This is commonly used in following scenarios

    • Approval process

    • Replications

    • Cluster

    Approval processes, Replications, and Cluster functionality connect via SOAP endpoints. Deployment in these scenarios does not usually require SSL protection because all registries are located in a dedicated internal network, but Oracle Service Registry can be configured to use client SSL certificates in these scenarios. When the registry on the other side is protected with Client SSL Authentication and plain HTTP connection is not allowed, your registry must connect with an SSL Certificate. This can be achieved by configuring destinationConfig inside security.xml. See the documentation for sslTool in the Administration Guide, which describes the tool for SSL related tasks and destinationConfig. Destination config allows you to specify different certificates for different endpoints by either specifying the SOAP stub or the URL prefix.

  • HTTPS protected resources

    • WSDL

    • XML

    • XSD

    • XSLT

    Resources which are downloaded for processing by Oracle Service Registry can be behind HTTPS protected by Client SSL Authentication. Oracle Service Registry can be set up so that these connections use a specified certificate. The certificate must be present as a key entry inside pstore.xml. This key entry is identified by its alias. The alias and password has to be specified in REGISTRY_HOME/app/uddi/conf/security.xml inside security which is contained in config as shown in example:

            <sslConnectionAlias>myAliasName</sslConnectionAlias>
            <sslConnectionPassword_coded>9vTJ9GKyjIURFY0qrWvADA==</sslConnectionPassword_coded>
               

    To get encoded password from clear-text password, use REGISTRY_HOME/bin/sslTool(.bat or .sh) with "encrypt" option.