The Security Token Service component of the WSO2 Carbon enables to configure the generic STS to issue claim based security tokens. This Security Token Service is capable of issuing SAML 1.1 and SAML 2.0 tokens as recommended in WS-Trust and SAML Web Service Token Profile specifications.
The WSDL of this service can be accessed by clicking through the URL : https://{hostname}:{port}/services/wso2carbon-sts?wsdl. For instance, with the default configuration it is https://localhost:9443/services/wso2carbon-sts?wsdl.
Both SAML 1.1 and SAML 2.0 token types are supported by default. The issued token type is decided based on the Token type defined in the RST(Request Security Token).
Currently Bearer Subject Confirmation and Holder-Of-Key subject confirmation methods are supported. With Holder-Of-Key, both Symmetric and Asymmetric key types are supported.
It is possible to obtain tokens containing claims which hold certain information about the subject. These claims can be extracted from the profiles or through custom claim callbacks which can be registered to the Carbon runtime.
This requires registration of relying party endpoint addresses and their corresponding public certificates. In this scenario, STS will generate a symmetric key and encrypts it with the public key of the relying party. This will be included in the subject confirmation section of the SAML token which will be validated at the relying party end.
Figure 1: STS Configuration
Most of the time it is required to secure the Security Token Service. According the Trust Brokering model defined in WS-Trust specification, the subject(user) should authenticate him self to the STS before obtaining its token. STS may use this authentication information when constructing the security token. For example, STS may populate the required claims based on the username provided by subject. You can apply a security policy for STS by clicking on 'Apply Security Policy' link and following the wizard.
Figure 2: Securing the STS - Step 1
Then select a pre configured security scenario according to your requirements.
Figure 3: Securing the STS - Step 2 - Selecting a security scenario
In the passive sts configuration, we can define the claims to be added for authentication response. The realm name should be equal to the wtrealm or wreply parameter as defined in ws passive federation specification. The user claims can be from any claim dialect. The claim uri is used to name the claims in the response element. Before requesting for passive sts for tokens, you need to register the realm name. These realms can be deleted in below table.
Figure 4: Passive sts configuration
External References: