Security Token Service Connector

Usage

For many Web services it is important for the service provider to recognize the users of the services, e.g. to be able to bill usage or to prevent unauthorized access. In the WSDL file in the interface description of their Web service, service providers can thus specify that computers have to authenticate themselves towards the Web service.

If a larger number of Web services is to be managed, it makes sense to externalize the authentication and to use a central authentication, a so called Security Token Service.

An STS (Security Token Service) acts as a central security gateway for communication between service consumers and service providers in terms of message and transport security.

The Security Token Service Connector can only be used in Single Mode.

Connector types

An STS Connector is always used as an Input Listener Connector. It validates incoming authentication requests and returns tokens if the validation was successful.

Standards

The STS Connector implements the following standards:

Principles

module guide 1156 1

Securing the communication between service consumers and providers via an STS works as follows:

  1. Service provider offers Web service and uses STS
    The service provider offers a service via a Web service. This Web service is secured via an STS.
    A Web service request is valid only, if it contains a valid token of the STS. Each time the provider receives a request from a consumer, it first checks the token’s validity. Depending on the token type the provider checks the certificate’s validity.

  2. Service consumer requests using service
    To be able to call up the service the consumer needs the service’s interface description, the so called WSDL file. This WSDL file can be requested directly from the service provider or from a directory service. In the WSDL file the security requirements are described which the consumer must meet to be able to use the service. Amongst others, it is defined against which STS the consumer must authenticate itself.
    Now, that the consumer knows the STS address, it can call up the STS and authenticate itself against it.

  3. STS provider checks request of the service consumer The STS provider checks the consumer request on basis of the included characteristics. These may be username/ password or the certificate, the request is signed with. If the check was successful, the STS generates two tokens:

    • For the first token the following applies:

      • It includes a session key with the information, whether the consumer has authenticated itself successfully.

      • The token is encrypted with the public key of the service provider. This guarantees that nobody except the service provider can read the session key.

      • The token is signed by the STS in order to assure that the STS has issued this token.

    • The second token is a test token, for which the following applies:

      • The test token also includes the session key. This is necessary so that the consumer can sign a Web service call.

      • The test token is encrypted by the public key of the consumer so that the consumer can seize the session key. The STS sends token and test token to the consumer.

  4. Service consumer calls up service provider
    The consumer receives both tokens and extracts the session key from the test token. It creates the Web services call and signs the call using the session key. Then the consumer sends the call and the STS token to the service provider.

  5. Service provider checks the signature of the token
    The service provider checks the token’s signature with the public key of the STS to verify whether the tokens really originates from the STS. Then, the provider decrypts the token with its private key and thus obtains the session key and the information included within about the consumer’s identity.
    On basis of the session keys the provider checks the Web service request’s signature. At this point in time only the STS, the consumer and the service provider know the session key, thus the service provider can assume that it is really the consumer, for whom the STS has issued the token, who has signed the service request. Now the service provider only needs to check whether the STS has integrated the required certificates into the token.

  6. Service provider sends service response or error message
    If the required certificates are integrated into the token, the service request is executed, the service response is encrypted, signed and send to the consumer.
    If the certificates are missing an error is returned.

Registering Web Services Providers at an STS Connector

This section explains how to register any Web services providers at an STS Connector, in order to secure them.

Prerequisites

  • The Web services that are to be secured are available and their URL are known.

  • The truststore containing the public key for each Web service provider that is to be secured is available.

Proceed as follows

  1. Create an STS Connector or open it for editing.

  2. In the Secured service providers area click Add. Refer to Dialog Security Token Service - WS Trust. The following dialog opens:

    module guide 1157 0
  3. In the Provider endpoint URI field, enter the URL of the Web service provider.

  4. Click Add truststore or certificate to add the certificate of the Web service provider with the public key.

  5. Close the dialog with OK.

  6. In the WSDL file, enter the alias of the added Web service’s certificate. The tc.CertAlias element must be adapted.

    For each web service provider an individual `tc:ServiceProvider `element is created. Pay special attention to the `endpoint `attribute in order to change the correct alias.

  7. Click Finish to store the changes.

  8. If your web services provider was created in the INUBIT software, you need to configure its communication with the STS.

    Refer to:

Dialog Security Token Service - WS Trust

You use this dialog to configure the authentication possibilities for the Security Token Service and to add service providers.

Service name

Name used by the STS to offer its service.

By default the name of the connector is used. You can change this value.

WSDL file

WSDL file containing the interface description for the STS, the paths to the keystore of the STS and to the truststore of the secured service provides and the corresponding passwords and aliases.

Transport security

For selecting an encryption method:

  • XML-Encryption
    The data contained in the transmitted message are encrypted with the XML Encryption standard.
    Refer to https://www.w3.org/TR/xmlenc-core/

  • SSL
    The SSL protocol facilitates an encrypted data transmission connection.

STS authentication

For adding the keystore:

  • Password
    Keystore password.

  • Keystore/Select file (button)
    For importing the keystore. After successful import the validity of the key is indicated.

Consumer authentication

  • X.509
    Authentication by means of an X.509 certificate. The file containing the certificates can be imported by clicking the Truststore button.

  • Username/password
    Authentication by means of a username/password validation which validates against a user administration.
    If you select both options, then both user administrations are checked. The validation is regarded as successful, if username/password match to the values in one of the user administrations.

    • Internal user administration
      Authentication is only possible for consumers that are listed as Process engine users.

    • Authentication by workflow
      Authentication of consumers is provided by the workflow against a backend system to validate, e.g., against an LDAP directory. You need to create the workflow yourself.
      If a workflow is defined, the last module of the workflows generates an output message containing a SAMLAssertion workflow variable. This variable contains authorization data. The data is transferred to the Web service provider and can be used for implementations based on authorizations.

Secured service providers

Used for registering Web services.

  • Provider endpoint URI
    Specifies the URL of the registered Web service.

  • Public Key is valid until
    Specifies the validity of the public key that is stored in the X.509 certificate and which is added here when registering a service provider.

  • Key information
    Lists all additional information contained in the certificate.