Oracle Service Bus Inbound Custom Authentication

In addition to supporting standard authentication mechanisms using security policies and HTPP basic authentication, OSB also supports custom authentication mechanism for inbound requests

Authentication can be implemented at two levels

• Transport level
• Message level

Transport level:

Transport level authentication mechanism resorts to sending authentication information in protocol headers and authentication providers validate the header

• Custom token in an HTTP header

Message level:
Message level authentication mechanism uses either actual business XML payload or SOAP header  to store the authentication data.Oracle Service Bus accepts and attempts to authenticate a username and password passed in a SOAP header/XML payload

•  For SOAP protocol based proxy services

                  1.Custom token in a SOAP header
                  2.Username/Password in a SOAP header

• For non-SOAP protocol based proxy services

                 1.Custom token in the payload of any XML-based proxy services
                 2.Username/Password in the payload of any XML-based proxy services

Let's talk about what is custom authentication token

Custom Authentication Token:

An authentication token is some kind of data, represented as XML or a string, that identifies an entity, such as an X509 client certificate. Typically, authentication tokens are designed to be used within specific security protocols.
A custom authentication token is an identity assertion token in a user-defined location in the request.  An identity assertion token is allowed in an HTTP header, in a SOAP header (for SOAP-based services), or in the payload of some non-SOAP proxy service. The Oracle Service Bus domain must include an Identity Assertion provider that supports the token type.Assertion provider that maps the client's credential to an Oracle Service Bus user. Oracle Service Bus uses this resulting username to establish a security context for the client


Oracle Service Bus uses the authenticated user to establish a security context for the caller. The security context established by authenticating a custom token or username and password can be used as the basis for outbound credential mapping and access control.

In this post I am going to talk about message level authentication(Username/Password in a SOAP header) 

In this mechanism client passes username/password information in SOAP header.Remember that this information can be passed in any identifiable XML elements and need not be named as UserName and PassWord 

Assume that we have designed a service to accept below request and let's see how we design proxy service to accept and process the authentication header

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://www.oracle.com">
<soapenv:Header>
<AuthenticationHeader>

<UserName>
<user123>  
</UserName>
<PassWord>
<pasword123>
</PassWord>
</AuthenticationHeader>
</soapenv:Header>
<soapenv:Body>
</soapenv:Body>
</soapenv:Envelope>    Proxy service configuration to accept  

1. Create a WSDL based proxy service
2. Go to  Security tab
3. Go to Custom Authentication section and select 'Custom User Name and Password' as Authentication Type
4. In User Name XPath, enter in same line  declare namespace ns1="http://www.oracle.com";./ns1:AuthenticationHeader/ns1:UserName/text()
5. In User Password XPath,enter in same line  declare namespace ns1="http://www.oracle.com";./ns1:AuthenticationHeader/ns1:PassWord/text()
6. Leave Context Properties  empty

user123 has to be configured in appropriate authentication provider of WLS
Test the proxy service by passing above sample request then OSB will authenticate the user and establish security context
Also try testing by passing wrong user name/password in the SOAP header then you will see authentication failure errors