The first step in protecting web services is to authenticate and authorize the web service requests. Authentication in web services is the process of verifying that the user has valid credentials to access the web services and authorization is the process of validating that the authenticated user has appropriate privileges to access the web services. Besides restricting access to users with valid credentials and proper privileges, Oracle WSM can track who accessed which service and when—to provide detailed audit trails. In this article, Sitaraman Lakshminarayanan explores how Oracle Web Services Manager can be leveraged to authenticate and authorize the web services requests.

Here, we will see:

• Steps involved in the authentication and authorization process
• Learning file authentication and authorization
• Implementing active directory authentication and authorization
• Details of policy template

Steps Involved in the Authentication and Authorization Process

Oracle Web Services Manager can authenticate the web services request by validating the credentials against a data store. The credentials (e.g. username and password, SAML token, certificate, etc.) that are attached to the web services will be validated against the data store, such as the file system, databases, active directory and any LDAP compliant directory. Once authentication is successful, the next step is to perform authorization by validating the username against a set of pre-defined groups which have access to the web service.

The following figure shows the process where the user accesses an application which acts as a client for the web service. The client application then attaches the username and password to make the web service request. The username and password are then validated against file system or LDAP directory by Oracle WSM, either using the gateway or the agent.

The authentication and authorization against different directory stores can be configured using Oracle WSM policy steps. Oracle Web Services Manager has predefined policy steps for:

• File Authenticate and Authorize
• Active Directory Authenticate and Authorize
• LDAP Authenticate and Authorize

In the previous figure, the Oracle WSM Gateway is used to protect the web services and externalize the security. In order to authenticate and authorize requests to web services, the web services can be registered within the gateway and the request pipeline of gateway will validate the credentials and authorize the access before it forwards the request to the actual web service provider. The gateway steps for authentication and authorization can be summarized as:

• Log incoming request (optional)
• Extract credentials get the credentials from the SOAP message or HTTP header)
• Authenticate (file authenticate, active directory authenticate, etc.)
• Authorize (file authorize, active directory authorize, etc.)
• Request is forwarded to the web service provider

The response from the web service also follows through a similar response pipeline where you can implement the log, encryption of response, or signing, or response, etc. While it is not required to implement any steps in the response pipeline, there should be a response pipeline even if it's doing nothing.

Oracle WSM: File Authenticate and Authorize

Oracle Web Services MManager can authenticate the web services requests against a file that has the list of usernames and passwords. In this example, the username and password information are part of the SOAP message, however one can also send a username and password as HTTP header, or it can be any XMML data that is a part of the web services message. While file-based authentication can easily be compromised, it is often used as a jump start or testing process to validate the authentication and authorization process.

Authentication and authorization of web service requests against a file requires three main steps, and these are described below. There is a default log step which will log all the request and response messages, and you can also include that log step at any point to log messages:

• Extract Credentials
• File Authenticate
• File Authorize

The first step to authenticate a web service request against a password file (file authenticate) is to extract the username and password credentials from the SOAP message. The client application attaches the username and password to the SOAP message, as per the UserName token profile.

In the policy to authenticate the web service against the file, add the step in the request process to extract credentials. Since this is a web service request, as opposed to HTTP post, configure the Credentials location to WS-BASIC (refer to the following screenshot).

Note: WS-BASIC means that it is WS-security compliant. WS-security is the oasis specification that specifies how security tokens are inserted as a part of the SOAP message. In other words, WS-BASIC means that the username and password can be found in the SOAP message, as per the username token profile of the WS-security specification.

Once the credentials are extracted, the next step is to validate them against the file. The default implementation of the Oracle WSM File Authenticate requires the username and password to be in a comma separated format and the password should be the hash value using a MMD5 or SHA1 algorithm.

In order to authenticate the credentials against the data store, the next step is to configure the File Authenticate step in Oracle WSMM. In this step, the options are straightforward. We have to configure the location of the password file and the hash algorithm format as either md5 or SHA1 (see the next screenshot).

The sample file with username and password is: bob:{MD5}jK2x5HPF1b3NIjcmjdlDNA==

You can use the wsmadmin tool provided as part of Oracle WSMM standalone or SOA suite). Type: wsmadmin md5encode bob password c;.htpasswd

A step-by-step guide to configuring, using, and adapting this free Open Source network monitoring system - with a Foreword by Mark R. Hinkle, VP of Community owsm Inc. Discover, manage, and monitor IT resources Build custom event processing and alerting rules Configure owsm Core via an easy to use web interface Drag and drop dashboard portlets with Google Maps integration http://www.PacktPub.com/oracle-web-services-manager/book

Now that the authentication steps are configured, the next step is to configure the authorization policy step to ensure that only valid users can access the web service. For the file authorization method, it is no different than the file authenticate method i.e. even the user-to-role mappings are kept in the file.

The following figure shows the File Authorize policy step. In this step, we have to define the location of the XML file that contains the users to roles mapping, and also the list of roles that should be allowed to access the service.

The roles XML file should look like:

<?xml version=‘1.0' encoding=‘utf-8'?>
<UserRoles>
 <user username="joe" roles="guest"/>
 <user username="Bob" roles="Admin,guest"/>
</UserRoles>

In the previous XML file, the list of roles the user belongs to are defined as a value of roles element and is comma separated.

Now that we have completed the steps to extract credentials, authenticate the request and also authorize the request, the next step is to save the policy steps and commit the policy changes. Once the policy is committed, any request to that web service would require a username and password, and that user should have necessary privileges to access the service.

Oracle WSM: Active Directory Authenticate and Authorize

In the previous section, we discussed authenticating and authorizing web service requests against a file. Though it's an easy start, security based on a file system can be easily compromised and will be tough to maintain. Authentication and authorization of web services are better handled when integrated with a native LDAP directory, such as active directory, so that the AD administrator can manage users and group membership. In this section, we will discuss how to authenticate and authorize web service requests against an active directory.

Active-directory-based authentication and authorization of web service requests involves the same steps as file-based-authentication and authorization, and they are:

• Extract Credentials
• Active Directory Authenticate
• Active Directory Authorize

The first step towards active-directory-based authentication and authorization is to extract the username and password credentials from the SOAP message. This step is the same for both file-based-authentication and active-directory-based authentication. The next screenshot describes how the Extract Credentials steps should be configured.

In the Extract Credentials step, the Credentials location should be changed to WS-BASIC since it is a web service invocation.

The second step is to authenticate the web service request against the active directory data store. Well, we know that the credentials i.e. username and password are attached to the SOAP message. Once the credentials are extracted from the SOAP message, we then have to define the following in order to authenticate the user against the active directory:

• Name of the active directory server
• Ports on which to communicate ((both plain text and SSL)
• Base distinguished name under which the user can be found
• Active directory domain name
• User attribute that uniquely identifies the user.

This information is then configured in the Active Directory Authenticate policy step.

In the previous figure, the sample Active Directory Authenticate policy step is configured to validate the user against:

• Packtpub active directory at Packtpub.com
• Listening on port 389 and 636
• With the domain name of packtpub.com
• The user can be found under DC=Packtpub, DC=com
• The unique user id attribute is samAccountName

Once this policy step is configured, the username and password will be validated against the packtpub active directory.

The next step is to ensure that only valid users can access the web service by defining the Active Directory Authorize policy step. In this step, Oracle WSMM will validate the authenticated user against the configured groups and will be granted access only if the user belongs to one of those groups. The following screen capture shows how the Active Directory Authorize step is configured.

In the previous figure, the AD Authorize policy step is configured to protect against ,TestGroup1 and TestGroup2. In the This step, you should also define the service account that can bind to the active directory.

A step-by-step guide to configuring, using, and adapting this free Open Source network monitoring system - with a Foreword by Mark R. Hinkle, VP of Community owsm Inc. Discover, manage, and monitor IT resources Build custom event processing and alerting rules Configure owsm Core via an easy to use web interface Drag and drop dashboard portlets with Google Maps integration http://www.PacktPub.com/oracle-web-services-manager/book

The AD baseDN should be a root distinguished name under which both users and groups are defined. Technically, users can be in a different container to the groups, but in the AD Authorize policy step, the AD baseDN should be the root of both the user's and group's container.

Once the AD Authenticate and Authorize steps are configured, the next step is to save the policy steps and then commit the policy. When the web service request is made with the appropriate username and password that belong to TestGroup1 or TestGroup2, they will be either granted or denied access to the service.

In the next section, we will take a closer look at what policy templates are and how they can be used in defining policy steps.

Oracle WSM: Policy Template

Policy templates are reusable policy steps that can be created once and used across multiple policies. It is not uncommon to have a similar sequence of steps to perform operations such as authentication, authorization, signature verification, etc. Instead of defining the same steps over and over again in each policy, it can be defined as a policy template in one place and then used when defining each policy step.

In the previous sections, we discussed authenticating users against an active directory. Imagine that each service should be authenticated against the same active directory; one has to define the same steps of Extract Credentials and AD authenticate across each policy. While Extract Credentials and AD Authenticate are mandatory, there is also an optional logging step that may be required to help troubleshoot the application. In the overall, the administrator has to:

• Create the log step and specify what information should be logged.
• Create the Extract Credentials steps in each policy and define if it is WS-BASIC or not.
• Create the AD Authenticate step and define the same AD user DN, uid attribute, etc.

When these steps are repeated across all services, it increases the administrative overhead and can also cause increase in the chances of manual data entry errors.

Defining the policy template for AD Authenticate for your environment would be ideal so that the default request template can be replaced with this new template. In order to define the policy template, the administrator has to go to the Pipeline Templates section and then create a new template.

In the previous figure, a new request pipeline template named ADAUTHENTICATE has been defined. Defining the pipeline template is exactly the same as configuring the steps in policy in the request pipeline section.

In this example, we defined a template that will:

• Log the request.
• Extract Credentials with WS-BASIC.
• Authenticate the user against the active directory using samaccountname as uid attribute.

Once this template is defined, in the policy section, when you want to authenticate the request against the active directory, you can replace the default request pipeline template with the ADAUTHENTICATE pipeline template.

In the previous figure, the default Request pipeline is replaced with the ADAUTHENTICATE pipeline template.

Once the template is chosen, it can then be modified to add any additional steps, and that will not affect the actual template.

Summary

In this article, we learnt the various steps involved in the authentication and authorization process, file authentication and authorization, active directory authentication and authorization, and details of policy template, all using Oracle WSM.

A step-by-step guide to configuring, using, and adapting this free Open Source network monitoring system - with a Foreword by Mark R. Hinkle, VP of Community owsm Inc. Discover, manage, and monitor IT resources Build custom event processing and alerting rules Configure owsm Core via an easy to use web interface Drag and drop dashboard portlets with Google Maps integration http://www.PacktPub.com/oracle-web-services-manager/book

About the Author

Sitaraman Lakshminarayanan is an Enterprise Architect with over 11 years of IT experience in implementing software solutions based on Microsoft and Java platforms. His area of interest is in enterprise architecture, application integration and information security, and he specializes in identity and access management, web services and SOA. He is a co-author of ASP.NET Security (Wrox publications) and has presented at regional and international conferences on web services security and identity management.