4.2.9 Configuring WS-Trust Security Token Service

This section describes WS-Trust Security Token Service (WS-Trust STS) and how to configure it. Topics include:

Overview

Web services are software applications that interact over network by using the Hyper Text Transfer Protocol (HTTP). World Wide Web Consortium (W3C) describes web services as a standard means of interoperating between software applications running on a variety of platforms and frameworks. A web service provides a fine-grained service to its client.

Web services use network for communication and data exchange spanning from protected network (intranet) to unprotected network (internet). This demands for security requirements such as client authentication, access control, data integrity, and confidentiality.

You can secure web services and protect your information against authentication attacks and unauthorized access by using security tokens. A security token contains a set of claims made by a client that includes details such as a user name, password, identity, key, and certificate.

Access Manager addresses the need for a secure token mechanism through WS-Trust STS that is based on the WS-Trust protocol. WS-Trust is built on top of the WS-Security specification. It enables web applications to construct trusted SOAP message exchanges.

WS-Trust STS provides secure communication and integration between services. It issues and validates security tokens to establish trust relationships between a web service client and a web service provider. If the requestor (web service client) does not have the necessary token to provide required claims to a service, it contacts WS-Trust STS and requests the needed tokens with proper claims. WS-Trust STS may in turn require its own set of claims for authenticating and authorizing the request for security tokens.

How WS-Trust STS Works

WS-Trust STS allows secure identity propagation and token exchange between web services. It provides a standard framework for requesting and returning security tokens by using Request Security Token (RST) and Request Security Token Response (RSTR) messages. RST provides the means for requesting a security token from WS-Trust STS. RSTR contains the requested token, claims, and other related information.

The web service client provides its credentials to WS-Trust STS and gets a SAML token from WS-Trust STS. A trust is established between the web service provider and WS-Trust STS. The web service client presents the token from WS-Trust STS to the web service provider. The web service provider validates if the token has been issued from WS-Trust STS and grants access to the required service.

The following diagram illustrates an example of how WS-Trust STS facilitates a secure communication between a web service client and a web service provider through security tokens:

WS-Trust STS is designed to interoperate with many different web service environments and supports SOAP and WS-Trust specifications.

Web services must implement the protocol defined in the WS-Trust 1.3 or 1.4 specification by making assertions based on evidence that it trusts, to whoever trusts it, or to specific recipients. For more information about WS-Trust specification, see WS-Trust 1.3 Specification and WS-Trust 1.4 Specification.

The following table lists supported SOAP and WS-Trust versions and corresponding namespaces:

Specification	Version	Namespace
Soap	1.1	http://schemas.xmlsoap.org/soap/envelope/
	1.2	http://www.w3.org/2003/05/soap-envelope
WS-Trust	1.3	http://docs.oasis-open.org/ws-sx/ws-trust/200512
WS-Trust	1.4	http://docs.oasis-open.org/ws-sx/ws-trust/200802

NOTE:

WS-Trust STS supports SAML tokens in addition to usernametokens.

WS-Trust STS can issue both SAML 1.1 and SAML 2.0 based tokens.
WS-Trust STS supports issuing, validating and renewing tokens. This release does not support canceling tokens.
Web service clients and web service providers must be in the same domain. This release does not support multiple domains.

Benefits

WS-Trust STS offers the following benefits:

Enables the secure exchange of SOAP messages among web services.
Facilitates identity delegation (through ActAs) and impersonation (through OnBehalfOf) where an authenticated user is granted access to downstream web services.
Reduces complexity for the web service consumer as the web service consumer does not need token specific knowledge.

Scenarios

This section describes the basic scenarios supported by WS-Trust STS.

Scenario 1: Web Service Client Communicating with Token Protected Web Service Provider

In this scenario, a web service client situated outside the enterprise tries to access a web service provider hosted inside the enterprise.

This process consists of requesting a token by means of the request-response message pairs of a Request Security Token (RST) and a Request Security Token Response (RSTR). The tokens are included in SOAP messages.

The following diagram illustrates this scenario:

A web service client, which is outside the enterprise, sends its credentials to WS-Trust STS and request for the security token through RST.
WS-Trust STS verifies the client’s credentials and then issues a security token (SAML token) through RSTR.

The web service client caches the security token and then uses it in multiple requests to the web service provider.
The web service client presents the token to the web service provider.
The web service provider validates the token and sends the response to the web service client.

Scenario 2: Web Single Sign-On and STS

In this scenario, a web service client that resides as part of a web application within an enterprise tries to access services from other web service providers of the same enterprise. A user named Alice accesses to the web application through a browser and needs single sign-on access to other applications.

A web application sends a single sign-on authentication request to WS-Trust STS on behalf of Alice.

The web application is residing within the enterprise.
The web application passes the credentials corresponding to the single sign-on session to the web service client.
The web service client requests for security token by using the passed on credentials.
WS-Trust STS verifies the credentials. After checking the credentials, it verifies if the web service provider for which the token has been requested for is a trusted service provider. Then it issues a security token consumable by the service provider.
The web service client residing within the web application presents the token to the web service provider. The web service client caches the security token and then uses it in multiple requests to the web service provider.
The web service provider validates the token and sends the response to the web service client residing within the web application.

The tokens are included in SOAP messages.

Scenario 3: Identity Delegation and Impersonation

In this scenario, a web service provider requests services from other web service providers.

The following use-case explains this scenario:

There are two web service providers called Service1 and Service2 providing some fine-grained service. Both Service1 and Service2 require authentication and trust WS-Trust STS. A web service client tries to access Service1 and requests for the service. To fulfill the request, Service1 needs to access the service of Service2. Service1 can request a token from WS-Trust STS to access Service2. This exchange of information happens through security tokens embedded in SOAP messages.

This chaining of service request can be any number of nodes based on the implementation.

Requests for tokens can be made in two ways:

By using the ActAs element (Identity Delegation): The ActAs element is used for delegated requests. Delegated scenarios require composite delegation, where the final recipient of the issued token can see the entire delegation chain. ActAs is commonly used in multi-tiered systems to authenticate and pass information about identities between the tiers without having to pass this information at the application or business logic layer.
By using the OnBehalfOf element (Impersonation): The OnBehalfOf element is used for proxy requests. OnBehalfOf is used when the identity of only the original client is important. The final recipient of the issued token can only see claims about the original client. The information about intermediaries is not preserved.

The following diagram illustrates the workflow:

The following workflow explains the ActAs scenario:

The web service client sends a RST to WS-Trust STS for its authentication.
WS-Trust STS returns a SAML token to the client in the RSTR. Let us refer to this SAML token as token1. The subject of this SAML token is client.
The client forwards the token1 with its SOAP request to Service1.
Then Service1 sends a RST to WS-Trust STS again authenticating itself to the STS. This time the RST contains the token1 inside the ActAs element.
WS-Trust STS issues a SAML token (referred to as token2). The subject of this token is Service1. It contains an attribute called ActAs with the value of client.
Service1 sends token2 to Service2. By processing token2, Service2 understands that the original requester is client and Service1 is acting as the original requester.
Service2 sends the response to Service1.
Service1 forwards the response to the client.

The following workflow explains the OnBehalfOf scenario:

The web service client sends a RST to WS-Trust STS for its authentication.
WS-Trust STS returns a SAML token to the client in the RSTR. Let us refer to this SAML token as token1. The subject of this SAML token is client.
The client forwards the token1 with its SOAP request to Service1.
Then Service1 sends a RST to WS-Trust STS again authenticating itself to the STS. This time the RST contains the token1 inside the OnBehalfOf element.
WS-Trust STS issues a SAML token (referred to as token2). The subject of this token is client.
Service1 sends token2 to Service2. Service2 understands that the original requester is client but cannot see the details of Service1.
Service2 sends the response to Service1.
Service1 forwards the response to the client.

IMPORTANT:Starting from Access Manager 4.0 SP1 release, the default binding supported is SOAP 1.2. If you want to use SOAP 1.1 instead, perform the following steps on all instances of Identity Server:

Traverse to the /opt/novell/nam/idp/webapps/nidp/WEB-INF folder and edit the sun-jaxws.xml file.
Remove all instances of bindings from the endpoints in the sun-jaxws.xml file and save the changes. A binding is represented by the following line in this file:

binding="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"
Restart Identity Server using the /etc/init.d/novell-idp restart command.

Renewing a Token

The renew token operation helps in renewing a token issued by WS-Trust Security Token Service(STS). Only a token that is issued by an Identity Server that is part of the same cluster can be renewed. Tokens issued by a different Identity Server in a different cluster or by a third-party STS cannot be renewed.

Each token generated by the STS is valid for the duration specified using the Token Lifetime setting. A token can be renewed only before lapse of the expiry period. For example: if the Token Lifetime has been specified as 180 seconds, token renew operation will succeed only till the 179th second.

Workflow:

The web service client sends a RST to WS-Trust STS for its authentication and WS-Trust STS returns a SAML token to the client in the RSTR
The web service provider uses the SAML token from STS and requests access to resources hosted on the web service provider.
The web service provider validates the SAML token and provides access to the resources.
When the token is nearing expiry, the web service client sends a RST to WS-Trust STS to renew the token previously issued. The STS renews the validity of the token and sends a renewed token to the web service client for any further requests.
The web service client uses the renewed SAML token from STS and requests access to resources hosted on the web service provider.

Authentication by Using SAML Tokens

WS-Trust STS accepts SAML tokens issued by a third-party STS for authentication. The tokens can be in SAML 1.1 or SAML 2.0.

Workflow:

The web service client sends a RST to third-party STS. The third-party STS returns a SAML token to the client in the RSTR.
The web service client uses SAML token issued by the third-party STS and requests WS-Trust STS to grant access to resources hosted on the web service provider.
WS-Trust STS authenticates the client using the third-party SAML token and issues a new SAML token.
The web service client uses this new SAML token to get access to resources hosted on the web service provider.
The web service provider validates the SAML token with WS-Trust STS.
The web service client can access the resources on the web service provider if the SAML token is valid.

Configuring WS-Trust STS

Before a web service can invoke operations on STS, you must enable WS-Trust and configure it in Access Manager. This section discusses the following topics:

Enabling WS-Trust

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. To use the WS-Trust protocol, you must enable it on Identity Server.

To enable WS-Trust, perform the following steps:

Click Devices > Identity Servers > Edit.
In the Enabled Protocols section, select WS-Trust.
Click OK.
Update Identity Server.

Configuring Access Manager for WS-Trust STS

To configure WS-Trust STS, perform the following steps:

Click Devices > Identity Servers > Edit.
Select WS-Trust > STS Configuration.
Specify the following details:

Token Lifetime: Specify the duration in seconds for which the token is valid. The default value is 360 seconds.

Token Issuer: Specify the name of the issuer of the authentication token.

Authentication Methods: Select methods that can be used for authentication at STS for WS-Trust.

Select and move methods from Available Authentication Methods to Selected Authentication Methods.

Tokens: Select the type of tokens that can be issued for authentication at STS for WS-Trust. SAML 1.1 and SAML 2.0 tokens are supported. If you select both token types, the token type configured in the service provider is returned.
Click Apply.

Viewing STS Service Details

EndPoint URL is the SOAP endpoint of STS. The web service client and web service provider must be configured to these endpoints.

In Administration Console Dashboard under Devices > Identity Servers > Edit > WS-Trust > EndPoint Summary, you can view the following STS EndPoint details:

Service Name: The name of the STS service endpoint that is configured in the web service client.

Port Name: The port that STS implements. This is configured in the web service client.

MEX EndPoint URI: The MetadataExchange endpoint of STS.

WSDL of STS Username authentication: WSDL location for username authentication. This file is used by applications that use the token service with username authentication.

WSDL of STS SAML authentication: WSDL location for SAML. This file is used by applications that use the token service with SAML authentication.

Configuring Service Providers

You need to configure web service providers to accept tokens issued by an STS. The web service provider uses an IssuedToken policy for the same. The IssuedToken policy is wrapped in WSDL. For a sample policy, see A Sample WS-Policy for Web Service Providers.

Configuring a service provider includes adding a service provider domain and then adding a service provider in a configured domain. Access Manager also allows you to modify and delete configured service provider domains and service providers.

Adding a Domain and Assigning WS-Trust Operations

Click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.
Click New > General to create a general domain. Selecting New > Office 365 creates an Office 365 domain that can be configured for active authentication. For details on creating an Office 365 domain, see Configuring an Office 365 Domain By Using WS-Trust Protocol
Specify the following details:

Name: Specify a name for the domain.

WS-Trust Operations: Select operations in Available operations that WS-Trust STS performs for tokens and move these to Selected operations.

The available operations are Issue, Validate, OnBehalfOf, ActAs and Renew.

If you select OnBehalfOf and Act As the Available operations, additional configuration is required. For more information, see Adding Policy for ActAs and OnBehalfOf
Click Finish. Continue with creation of a trusted Service Provider. For more information, see Adding Web Service Providers

Adding Web Service Providers

This section discusses how to add service providers for WS-Trust STS. Adding a service provider includes adding service provider EndPoint URL, configuring trust certificates, selecting token types, and customizing attributes.

Perform the following steps:

Click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.
Select the domain under which you want to configure a service provider.
Click Service Provider > New.
Specify the following details:

Name: Specify a name for the service provider.

Endpoint: Specify the SOAP endpoint location at the service provider to which SOAP messages are sent.

Token Type: Select the type of token that the service provider will accept or validate.

Encrypt Proof Token Using: Import a certificate from the file system or paste content of the certificate here. This certificate must be configured in the web service provider and is used for creating the subject confirmation in the SAML token.
Click Finish.
Select the Service Provider to define the Attributes and Authentication Response. For more information, see Modifying Service Providers

Enabling Delegation and Impersonation

By default, ActAs and OnBehalfOf requests are disabled in the Access Manager Identity Server. To enable delegation and impersonation, you must enable ActAs and OnBehalfOf by performing the following steps:

Go to WS-Trust > Service Provider Domain.
Click the service provider domain name for which you want to enable ActAs and OnBehalfOf operations.
Under WS Trust Operations, select ActAs and OnBehalfOf in Available operations and move to Selected operations.
Click OK.

These operations are restricted to a set of privileged user accounts defined in the policy. You need to configure the allowed user accounts, who can perform ActAs and OnBehalfOf operations, in the nidconfig.properties file of each Identity Server installation. For more information, see Adding Policy for ActAs and OnBehalfOf

Configuring ActAs to Lookup Multiple User Stores

For ActAs, the username on behalf of whom a client requests for a token must be present in the user store (eDirectory). The default implementation checks for this user only in the default user store. If you want to search the user in a different user store, perform the following steps:

Click Devices > Identity Server > Edit > Local > Classes.
Click New and specify the following details:

Display name: Specify Find_By_Username

Java class: Select Other

Java class path: Specify com.novell.nidp.authentication.local.UserNameAuthenticationClass
Click Next > Finish.
Go to Local > Methods.
Click New and select the Find_By_Username class.

For more information about how to configure an authentication method, see Section 4.1.3, Configuring Authentication Methods.
Go to WS-Trust > STS Configuration. Move this authentication method in the Selected Authentication Methods from Available Authentication Methods.

Adding Policy for ActAs and OnBehalfOf

You must add an policy to allow ActAs and OnBehalfOf operations. The default policy looks for a configuration of allowed user names from the nidpconfig.properties file. Allowed usernames are the user accounts that the intermediate web service provider uses to authenticate with STS when sending a request with ActAs or OnBehalfOf elements.For ActAs and OnBehalfOf, you must specify multiple username values separated with comma. If no value is specified, ActAs and OnBehalfOf are denied.

Click Devices > Identity Servers > Edit > Options.
Click New.

Set the following properties based on your requirement:

Property Type	Property Value
WSTRUST AUTHORIZATION ALLOWED ACTAS VALUES	Specify the user names who can perform ACTas operations. Allowed user names are the user accounts that the intermediate web service provider uses to authenticate with STS when sending a request with Actas elements.
WSTRUST AUTHORIZATION ALLOWED ONBEHALF VALUES	Specify the user names who can perform OnBehalfOf operations. Allowed user names are the user accounts that the intermediate web service provider uses to authenticate with STS when sending a request with OnBehalfOf elements.
WSTRUST AUTHORIZATION ALLOWED VALUES	Specify the user names who can perform both Actas and onBehalfOf operations.

Click OK > Apply.
Restart Identity Server by running the following command:

After upgrading Access manager, the configuration is set to default values. You must reconfigure the details after each upgrade.

Linux: /etc/init.d/novell-idp restart

Windows: net stop Tomcat8

net start Tomcat8

Managing Service Provider Domains

The WS-Trust page allows you to create, modify, and delete service provider domains. This page lists all configured service provider domains.

Click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domains.

The list of all configured service provider domains is displayed.
Select one of the following actions:
- New: Select New > General to create a general domain. Selecting New > Office 365 creates a domain that can be configured for single sign-on to Office 365 services. For more on creating Office 365 domain, see Adding a Domain and Assigning WS-Trust Operations.
- Delete: Deletes the selected service provider domain.
Click OK, then update Identity Server.
Select the Service Provider domain to modify the following details:
- Name: Modify the name of the service provider domain.
- WS Trust Operations: Modify the list of selected WS-Trust operations.
Click OK.

Managing Service Providers

Access Manager allows you to you to create, modify, and delete trusted service providers. The Service Providers page lists all configured service provider.

Click Devices > Identity Servers > Edit > WS-Trust> Service Provider Domains> [name of the service provider domain] > Service Providers.

The list of all configured service provider for the selected domain is displayed.
Select one of the following actions:
- New: Launches the Create a Service Provider page. For more information, see Adding Web Service Providers.
- Delete: Deletes the selected service providers.
Click OK.

Modifying Service Providers

Click Devices > Identity Servers > Edit > WS-Trust> Service Provider Domains> [name of the service provider domain] > Service Providers.

The list of all configured service provider for the selected domain is displayed.
Click the name of the service provider you want to edit.

Configuration > Trust

You can modify the following details:
- Name
- Endpoint
- Token Type
- Encrypt Proof Token Using
  
  For more information about these fields, see Adding Web Service Providers.
Configuration > Attributes
- Select the Attribute Set and move attributes from the Available list to the Send with Authentication pane. This indicates the attributes that you want sent in an assertion to the service provider.
Configuration > Authentication Response
- Specify a value for the name identifier.
  - The persistent and transient formats are generated automatically. For the others, you can select an attribute. The available attributes depend upon the attributes that you have selected to send with authentication (see Configuring the Attributes Obtained at Authentication). If you do not select a value for the E-mail, Kerberos, X509, or Unspecified format, a unique value is automatically generated.
    
    IMPORTANT:In Access Manager 4.0 SP1, the SAML tokens with Name Identifier value other than username do not support ActAs, OnBehalfOf and SAML authentication operations.
Click Apply.

A Sample WS-Policy for Web Service Providers

You must modify WSDL of a web service provider to include IssuedTokenPolicy that points to Access Manager WS-Trust STS. To modify WSDL, you need to add a WS-Policy with IssuedTokenElement. The following is a sample configuration:

<wsp:Policy wsu:Id="<policy_name>">
        <wsp:ExactlyOne>
            <wsp:All>
                <wsaws:UsingAddressing xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl" wsp:Optional="false"/>
                <sc:KeyStore wspp:visibility="private" alias="xws-security-server"/>
                <sp:SymmetricBinding>
                    <wsp:Policy>
                        <sp:ProtectionToken>
                            <wsp:Policy>
                                <sp:IssuedToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                                    <sp:RequestSecurityTokenTemplate>
                                        <t:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</t:TokenType>
                                        <t:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>
                                        <t:KeySize>256</t:KeySize>
                                    </sp:RequestSecurityTokenTemplate>
                                    <wsp:Policy>
                                        <sp:RequireInternalReference/>
                                    </wsp:Policy>
                                    <sp:Issuer>
                                        <wsaws:Address>https://namtest.com:8443/nidp/wstrust/sts</wsaws:Address>
                                        <wsaws:Metadata>
                                            <wsx:Metadata>
                                                <wsx:MetadataSection>
                                                    <wsx:MetadataReference>
                                                        <wsaws:Address>https://namtest.com:8443/nidp/wstrust/sts/mex</wsaws:Address>
                                                    </wsx:MetadataReference>
                                                </wsx:MetadataSection>
                                            </wsx:Metadata>
                                        </wsaws:Metadata>
                                    </sp:Issuer>
                                </sp:IssuedToken>
                            </wsp:Policy>
                        </sp:ProtectionToken>
                        <sp:Layout>
                            <wsp:Policy>
                                <sp:Lax/>
                            </wsp:Policy>
                        </sp:Layout>
                        <sp:IncludeTimestamp/>
                        <sp:OnlySignEntireHeadersAndBody/>
                        <sp:AlgorithmSuite>
                            <wsp:Policy>
                                <sp:Basic128/>
                            </wsp:Policy>
                        </sp:AlgorithmSuite>
                    </wsp:Policy>
                </sp:SymmetricBinding>
                <sp:Wss11>
                    <wsp:Policy>
                        <sp:MustSupportRefIssuerSerial/>
                        <sp:MustSupportRefThumbprint/>
                        <sp:MustSupportRefEncryptedKey/>
                    </wsp:Policy>
                </sp:Wss11>
                <sp:Trust10>
                    <wsp:Policy>
                        <sp:MustSupportIssuedTokens/>
                        <sp:RequireClientEntropy/>
                        <sp:RequireServerEntropy/>
                    </wsp:Policy>
                </sp:Trust10>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

Configuring Web Service Clients

Access Manager WS-Trust STS can be accessed from various web service clients. The following sections provide example configurations and sample code snippets for CXF-based and Metro-based web service clients:

Configuring Apache CXF-based Web Service Clients

You can configure CXF-based web service clients either programmatically or through XML configuration files. Below is a sample XML configuration. Add the following features to cxf.xml under the top-level beans section:

<cxf:bus>
    <cxf:features>
      <cxf:logging />
      <wsa:addressing />
    </cxf:features>
  </cxf:bus>

Define the STS client with its properties as follows:

<jaxws:client name="{<your webservice target namespace>}WebServicePort"
    createdFromAPI="true">
    <jaxws:properties>
<entry key="ws-security.sts.client">
        <bean class="org.apache.cxf.ws.security.trust.STSClient">
          <constructor-arg ref="cxf" />
          <property name="wsdlLocation"
            value="https://<your idp base url>nidp/wstrust/sts?wsdl" />
          <property name="serviceName" value="{http://www.netiq.com/nam-4-0/wstrust}SecurityTokenService" />
          <property name="endpointName" value="{http://www.netiq.com/nam-4-0/wstrust}STS_Port" />
    
          <property name="wspNamespace" value="http://schemas.xmlsoap.org/ws/2004/09/policy" />
          <property name="properties">
            <map>
              <entry key="ws-security.username" value="<username to connect to idp>" />
              <entry key="ws-security.password" value="<password>" />
              <entry key="ws-security.encryption.properties" value="clientKeystore.properties" />
              <entry key="ws-security.encryption.username" value="mystskey" />
              <entry key="soap.force.doclit.bare" value="true" />
              <entry key="soap.no.validate.parts" value="true" />
            </map>
          </property>
        </bean>
      </entry>
</jaxws:clien>

You can configure ws-security.callback-handler to provide username and password programmatically. You can also configure global sts-client in cxf.xml that can be used across multiple web services.

For more information about configuring Apache CXF-based web service clients, see Apache CXF.

Configuring Metro-based Web Service Clients

You can configure Metro-based clients through NetBeans (an integrated development environment).

Create a web service client project in NetBeans.
Right click the project and click Create Web Service Client to create a STS client. Point the WSDL to http://<name of the identity provider server>:<port>/nidp/wstrust/sts?wsdl.
Configure the username and password to access WS-Trust STS.

The user configured needs to get authenticated into Access Manager password-based authentication classes. You can also configure the Callback-based configuration in NetBeans to provide username and passwords dynamically.
When you create a web service client for your web service, which is configured for STS-issued tokens, you need to specify the endpoint URL of WS-Trust STS in the web service client properties. You can specify this in NetBeans by right clicking Web Service References> Web Service and selecting Secure Token Service.

For more information about configuring Metro-based web service clients, see To Specify an STS on the Service Side and To Specify an STS on the Client Side in Configuring A Secure Token Service (STS).

Renew Token - Sample Request and Response

Renew Token - Sample Request

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
      <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9cfedcee-2ebf-47e0-a24a-45281d785136</MessageID>
      <To xmlns="http://www.w3.org/2005/08/addressing">https://namsb.blr.novell.com:443/nidp/wstrust/sts</To>
      <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
         <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
      </ReplyTo>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
         <wsu:Timestamp wsu:Id="TS-1">
            <wsu:Created>2014-02-10T23:36:42Z</wsu:Created>
            <wsu:Expires>2014-02-10T24:36:42Z</wsu:Expires>
         </wsu:Timestamp>
         <wsse:UsernameToken wsu:Id="UsernameToken-2">
            <wsse:Username>admin</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">novell</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soap:Header>
   <soap:Body>
      <wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Renew</wst:RequestType>
         <wst:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</wst:TokenType>
         <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
         <wst:Entropy>
            <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">2O0dAaqhrBJqbouiQTf7D2pXtXRo36Wi/yswGeoq7iQ=</wst:BinarySecret>
         </wst:Entropy>
         <wst:RenewTarget>
            <saml2:Assertion ID="nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196" IssueInstant="2014-05-26T10:33:50.564Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns10="http://www.w3.org/2000/09/xmldsig#" xmlns:ns13="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ns3="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:ns5="http://docs.oasis-open.org/ws-sx/ws-trust/200512/" xmlns:ns9="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
               <saml2:Issuer>https://namsb.blr.novell.com/nidp/wstrust/sts</saml2:Issuer>
               <ds:Signature>
                  <ds:SignedInfo>
                     <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                     <ds:Reference URI="#nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196">
                        <ds:Transforms>
                           <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                           <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>Z3S4qxz2wRv0k5np2R6ENkIF9pk=</ds:DigestValue>
                     </ds:Reference>
                  </ds:SignedInfo>
                  <ds:SignatureValue>ZxeqeuD7NXfNRPiaYY3v2Nfo9vTx+ceASiAFBDzOfaWGczHBT0eYU+AQM99vdX1GCBCdWqO9qQR8
2WP71mzREC6ndg+8g/zJ6UH+Jzsf05hIxCAu7d7fg5qP5/BP++x8vUlpUQ32D8daxx+GIwuZjlOs
8KhdbgLReYSWyX6PV0UbjbnAtDFaBTTJ5lpEqHdK7FGUiISXg679o16BTJSs/V2bBOrX7cZGRGte
PMBGz19qX0rzoeNpLJFpJi23+/wAYaqzz0kyRGeyA0De0ugsqw2XRvUPciaYhbqqOraFUfmpyspC
o7ClzwsvnO1h1gVX/lDBwfLokrBeijsG3FN3Hg==</ds:SignatureValue>
                  <ds:KeyInfo>
                     <ds:X509Data>
                        <ds:X509Certificate>MIIFBDCCA+ygAwIBAgIkAhwR/6b9CQnrHMhxuBSYqOCbHugRb+e4U/9jWi9kAgIWCzKcMA0GCSqG
SIb3DQEBBQUAMDExGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENBMRMwEQYDVQQKFApuYW1zYl90
cmVlMB4XDTE0MDUyMTE4NTQwMVoXDTI0MDUyMTE4NTQwMVowHzEdMBsGA1UEAxMUbmFtc2IuYmxy
Lm5vdmVsbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRTsdCFBM3ImpIyRAj
OdFFEYbC/ykQUEZFwGp62BAUxoLIOpmDZyxpbqIh+l462GFByuCvkLOhnelOGV6Ii/cTAbaHko7h
T7cfUC3N4kmhnc3IXWgjodRIXMlaUSYDYd79guyVjG0brOWJMxJxvm1eo3p8bFzPLnpkEdJ7c8HM
BRqckecaGT8nbpm1KGZFAStrRRTryu2aG670FP3+MHWZmydqLlvrK1NCfe+7DlpOUwA13sSgMslf
6UCI4E50gn6pQ26rctGKrBsFfrX76t6ESZuaqFlWS+YA11cWS3irtihT0p2GsoxcJzq+IvHosHY+
pvrt4gcJiZJN6P3e6yrrAgMBAAGjggIUMIICEDAdBgNVHQ4EFgQUpSkUiviZFQ7yIDLb9sJT+mZH
kngwHwYDVR0jBBgwFoAUfFLP7EF6tU2u2qquPNTvLDdV7e8wggHMBgtghkgBhvg3AQkEAQSCAbsw
ggG3BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9w
ZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFI
oBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEAMAgwBgIBAQIBADAIMAYCAQECAQACAQCi
BgIBFwEB/6OCAQSgWAIBAgICAP8CAQADDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQAC
CH//////////AQEAAgQG8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQAD
DQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/6b9MBgwEAIB
AAIIf/////////8BAQACBBH/pv2iTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAA
AAAAMBIwEAIBAAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUF
AAOCAQEAbA0AdHm5pV6cEwSyOoB3aJfaLegMYPlAuTNK9ajhez9PIHPGSQzNxTRbj3eV9P+ueP7j
i8AFVR3Ej4eA7S1i5kPGuSXhwM6VhSIsCn+x+HbpnFdWJdu5EvErjTIbbjRU/4wTRCqKe7loFqKs
rH+BGNuUJw16l2PM+wJ+sajX7ktzP8rk8CF+cTOe8ggFcEuJ4igl1MMkVbul1RTggRmpcILNFk57
QdmySozjVok1OVQOzIGcAggPBSZeCumNNP8mQIAmvnwWG0cTvDIkMkCV1AzCC0WK0dWM53JZD/aa
tHay9w8QWoUU5cJo8B+uSm2vN+53PdtMKWOXhJcXtXpKKg==</ds:X509Certificate>
                     </ds:X509Data>
                  </ds:KeyInfo>
               </ds:Signature>
               <saml2:Subject>
                  <saml2:NameID NameQualifier="">admin</saml2:NameID>
                  <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
               </saml2:Subject>
               <saml2:Conditions NotBefore="2014-05-26T10:33:50.564Z" NotOnOrAfter="2014-05-26T10:35:50.564Z">
                  <saml2:AudienceRestriction>
                     <saml2:Audience>http://164.99.184.228:8080/doubleit/services/doubleit</saml2:Audience>
                  </saml2:AudienceRestriction>
               </saml2:Conditions>
               <saml2:Advice/>
               <saml2:AuthnStatement AuthnInstant="2014-05-26T10:33:50.564Z">
                  <saml2:AuthnContext>
                     <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:1.0:am:password</saml2:AuthnContextClassRef>
                  </saml2:AuthnContext>
               </saml2:AuthnStatement>
               <saml2:AttributeStatement>
                  <saml2:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" Name="emailaddress" NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
                     <saml2:AttributeValue>admin@idp.com</saml2:AttributeValue>
                  </saml2:Attribute>
               </saml2:AttributeStatement>
            </saml2:Assertion>
         </wst:RenewTarget>
      </wst:RequestSecurityToken>
      <ns:RequestSecurityToken xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"/>
   </soap:Body>
</soap:Envelope>

Renew Token - Sample Response

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <S:Header>
      <Action S:mustUnderstand="true" xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/RenewFinal</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:f41d7aeb-6f67-4df3-9fe4-e160889b7efb</MessageID>
      <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9cfedcee-2ebf-47e0-a24a-45281d785136</RelatesTo>
      <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
      <wsse:Security S:mustUnderstand="true">
         <wsu:Timestamp wsu:Id="_1" xmlns:ns15="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/">
            <wsu:Created>2014-05-26T10:35:41Z</wsu:Created>
            <wsu:Expires>2014-05-26T10:40:41Z</wsu:Expires>
         </wsu:Timestamp>
      </wsse:Security>
   </S:Header>
   <S:Body>
      <trust:RequestSecurityTokenResponse xmlns:ns10="http://www.w3.org/2000/09/xmldsig#" xmlns:ns13="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ns3="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:ns5="http://docs.oasis-open.org/ws-sx/ws-trust/200512/" xmlns:ns9="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
         <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
         <trust:RequestedSecurityToken>
            <saml2:Assertion ID="nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196" IssueInstant="2014-05-26T10:35:41.072Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
               <saml2:Issuer>https://namsb.blr.novell.com/nidp/wstrust/sts</saml2:Issuer>
               <ds:Signature>
                  <ds:SignedInfo>
                     <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                     <ds:Reference URI="#nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196">
                        <ds:Transforms>
                           <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                           <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>bX5LSfro0HkupLsMkU/V+x39P+g=</ds:DigestValue>
                     </ds:Reference>
                  </ds:SignedInfo>
                  <ds:SignatureValue>QLRRXQ4TzTgM9mVa5UF1p7YRqRvLP/h3pyP0KVzZXcbCfDmtT4bO14lqfhNoXL+Ym2iu2V1MIC5I
TRSt6D/y6pfs4/nChMrOuk5spMZYLBee+0PdlGYhfLGzyh/AONZGsoVrHf1/LItMeTp4MVmk/hTp
8yTWb0r79Ssz5TEbwJ/NkqFXxa9XffheaTySOfNXQYu3tL1rdp7Zaq5BR7mye00huo6gBTshHTXM
fGPYMu/Sy0kapqTBWHUbwt8FzysBEgELZdquhuvt1NOfHqkWAbyp5vExjjrYxl06Z7Fu3LnDSq+m
hI9S+VLs1bBR2XgNofhw/bFVBboYkzZDT6Ipmg==</ds:SignatureValue>
                  <ds:KeyInfo>
                     <ds:X509Data>
                        <ds:X509Certificate>MIIFBDCCA+ygAwIBAgIkAhwR/6b9CQnrHMhxuBSYqOCbHugRb+e4U/9jWi9kAgIWCzKcMA0GCSqG
SIb3DQEBBQUAMDExGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENBMRMwEQYDVQQKFApuYW1zYl90
cmVlMB4XDTE0MDUyMTE4NTQwMVoXDTI0MDUyMTE4NTQwMVowHzEdMBsGA1UEAxMUbmFtc2IuYmxy
Lm5vdmVsbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRTsdCFBM3ImpIyRAj
OdFFEYbC/ykQUEZFwGp62BAUxoLIOpmDZyxpbqIh+l462GFByuCvkLOhnelOGV6Ii/cTAbaHko7h
T7cfUC3N4kmhnc3IXWgjodRIXMlaUSYDYd79guyVjG0brOWJMxJxvm1eo3p8bFzPLnpkEdJ7c8HM
BRqckecaGT8nbpm1KGZFAStrRRTryu2aG670FP3+MHWZmydqLlvrK1NCfe+7DlpOUwA13sSgMslf
6UCI4E50gn6pQ26rctGKrBsFfrX76t6ESZuaqFlWS+YA11cWS3irtihT0p2GsoxcJzq+IvHosHY+
pvrt4gcJiZJN6P3e6yrrAgMBAAGjggIUMIICEDAdBgNVHQ4EFgQUpSkUiviZFQ7yIDLb9sJT+mZH
kngwHwYDVR0jBBgwFoAUfFLP7EF6tU2u2qquPNTvLDdV7e8wggHMBgtghkgBhvg3AQkEAQSCAbsw
ggG3BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9w
ZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFI
oBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEAMAgwBgIBAQIBADAIMAYCAQECAQACAQCi
BgIBFwEB/6OCAQSgWAIBAgICAP8CAQADDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQAC
CH//////////AQEAAgQG8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQAD
DQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/6b9MBgwEAIB
AAIIf/////////8BAQACBBH/pv2iTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAA
AAAAMBIwEAIBAAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUF
AAOCAQEAbA0AdHm5pV6cEwSyOoB3aJfaLegMYPlAuTNK9ajhez9PIHPGSQzNxTRbj3eV9P+ueP7j
i8AFVR3Ej4eA7S1i5kPGuSXhwM6VhSIsCn+x+HbpnFdWJdu5EvErjTIbbjRU/4wTRCqKe7loFqKs
rH+BGNuUJw16l2PM+wJ+sajX7ktzP8rk8CF+cTOe8ggFcEuJ4igl1MMkVbul1RTggRmpcILNFk57
QdmySozjVok1OVQOzIGcAggPBSZeCumNNP8mQIAmvnwWG0cTvDIkMkCV1AzCC0WK0dWM53JZD/aa
tHay9w8QWoUU5cJo8B+uSm2vN+53PdtMKWOXhJcXtXpKKg==</ds:X509Certificate>
                     </ds:X509Data>
                  </ds:KeyInfo>
               </ds:Signature>
               <saml2:Subject>
                  <saml2:NameID NameQualifier="">admin</saml2:NameID>
                  <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
               </saml2:Subject>
               <saml2:Conditions NotBefore="2014-05-26T10:35:41.072Z" NotOnOrAfter="2014-05-26T10:37:41.072Z">
                  <saml2:AudienceRestriction>
                     <saml2:Audience>http://164.99.184.228:8080/doubleit/services/doubleit</saml2:Audience>
                  </saml2:AudienceRestriction>
               </saml2:Conditions>
               <saml2:Advice/>
               <saml2:AuthnStatement AuthnInstant="2014-05-26T10:33:50.564Z">
                  <saml2:AuthnContext>
                     <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:1.0:am:password</saml2:AuthnContextClassRef>
                  </saml2:AuthnContext>
               </saml2:AuthnStatement>
               <saml2:AttributeStatement>
                  <saml2:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" Name="emailaddress" NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
                     <saml2:AttributeValue xmlns:soap="http://www.w3.org/2003/05/soap-envelope">admin@idp.com</saml2:AttributeValue>
                  </saml2:Attribute>
               </saml2:AttributeStatement>
            </saml2:Assertion>
         </trust:RequestedSecurityToken>
         <trust:Lifetime>
            <wsu:Created>2014-05-26T10:35:41.071Z</wsu:Created>
            <wsu:Expires>2014-05-26T10:37:41.071Z</wsu:Expires>
         </trust:Lifetime>
      </trust:RequestSecurityTokenResponse>
   </S:Body>
</S:Envelope>