On Identity and Security

OpenSSO (http://opensso.dev.java.net) now provides WS-Trust implementation for token exchanges.

In general securing web services involves establishing trust between the web service client (WSC) and the web service provider (WSP). And for services provided on behalf of a user (for example a calendar service), the WSP would have to trust the WSC to have authenticated the user, or the WSC would have to include the user's credentials (such as username/password, authentication assertions, etc.) as part of the web service request. Although this works good, it involves the business logic to insert this information and becomes difficult to modify later. Another option is to provide the user's credentials or tokens as part of the web service security headers, verified by WSPs termed as Identity Web Services. The distinguishing fact here is that Identity Web Services authenticates both web service clients as well as user identity.

Securing identity web services can be accomplished using any of the Web Service Security Basic Token Profiles (WS-I BSP) or using Liberty tokens. The key here is that the user's security token must be included in the web service security header by the WSC.

The newly released NetBeans Enterprise Pack 5.5 (currently in beta) has greatly simplified securing identity web services using Liberty tokens. The NetBeans tutorials explains the use of WS-I BSP security mechanisms for securing web services. However securing identity web services requires few additional steps (explained below) at the WSC after selecting "LibertyDiscoverySecurity" mechanism in the drop down menu. However for the WSP, the selection of either "Liberty Bearer Token" of "Liberty X509 Token" would suffice. BTW, I assume you have gone over the tutorial and are familiar with configuring the security mechanisms.

The issue at the WSC is that user must be authenticated so that WSC can send the user's security token to WSP. In order to authenticate the user, the deployment descriptors i.e., web.xml and sub-web.xml must be modified as follows. In web.xml, the following security constrains must be added to protect the WSC

    <security-constraint>
        <display-name>Access Manager Security Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>AUTHENTICATED_RESOURCE</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>AUTHENTICATED_USERS</role-name>
        </auth-constraint>
    </security-constraint>

Additionally in sun-web.xml, we need to enable user authentication by providing a "Http" handler by replacing the following line:

    <sun-web-app error-url="">

with

    <sun-web-app error-url="" httpservlet-security-provider="AMHttpProvider">

Secondly, the security role mapping must also be provided after the definition for the <context-root>

  <security-role-mapping>
    <role-name>AUTHENTICATED_USERS</role-name>
    <principal-name>AUTHENTICATED_USERS</principal-name>
  <security-role-mapping>

After making the above changes and redeploying "Stock Client" and "Stock Service" would require the user to authenticate before accessing the WSC. The Access Manager bundled with NetBeans provide couple of sample users: jsmith and jondoe with passwords same as the user name. Analyzing the web service request would now show the user's identity being sent as part of the web service security headers.

The release of NetBeans Enterprise Pack 5.5 Beta includes the web archive (war file) of Access Manager 7.1 Beta. The war file is placed within Sun Application Server's install directory under "addons/amserver" as "amserver.war". By default NetBeans installation deploys the war file within the Application Server under the URI "/amserver".

However the war file can deployed in other servlet containers. Once deployed within the servlet container, the first access to the web application provides a very simple configuration page. Configuration takes less than a minute and Access Manager is ready for use.

The directory to store the Access Manager's configurations is the most important parameter. After installation this directory can be backed up as needed to recover back to a know state. BTW, this assumes that the data store used to manage identities is "files".

Instructions to uninstall Access Manager can be found in NetBeans Trouble shooting guide under "NoClassDefFoundError: cannot access amserver occurs during installation". Basically the steps are to undeploy the web application and to remove the configuration directory. Additionally, Access Manager maintains a bootstrap file $HOME\AMConfig_server_amserver_, the last component being the deploy URI. This file must also be deleted. However before redeploying Access Manager, the servlet container must be restarted to clear the initialized static variables.

The NetBeans Enterprise Pack 5.5 Beta is out today and can downloaded from Sun developer site or alternatively from NetBeans. This release has support for securing web services using WS-I BSP security mechanism such as SAML, X509 and Username tokens, and additionally using Libery Security mechanisms. Over the next few weeks, I plan to test this out and will be writing my findings, tips and tricks. So stay tuned.