This topic provides instructions on how to add a new service provider. You must provide configuration details to add this service provider in the WSO2 Identity Server so that the authentication and/or provisioning happens as expected. For more information on how the service provider fits in to the WSO2 IS architecture, see Architecture.
The responsibility of the service provider configuration is to represent external service providers. The service provider configurations cover the following:
- Define how the service provider talks to the Identity Server inbound authenticator
This is via inbound authenticators. When you register a service provider, you need to associate one or more inbound authenticators with it. - Define how to authenticate users.
This can be via a local authenticator, request-path authenticator or federated authenticator. Based on this configuration, the Identity Server knows how to authenticate the user when it receives an authentication request (via an inbound authenticator) and based on the service provider who initiates it. - Maintain claim mapping.
This is to map the service provider's own set of claims to the Identity Server's claims. For example, WSO2 Identity Server (WSO2 IS) has a claim called work email (http://wso2.org/claims/emails.work
) but your service provider application expects to receive a value named email. If the service provider application receives a value named work email, it does not recognize it as it does not recognize it. Therefore, to ensure that the values sent by WSO2 IS is understood and recognized by the service provider application, you can use claim mapping.
When the authentication framework hands over a set of claims (which it gets from the local user store or from an external identity provider) to the response builder of the inbound authenticator, the framework talks to the service provider configuration component, find the claim mapping and do the claim conversion. See Configuring Inbound Authentication for a Service Provider for more information about response builder. Now the response builder will receive the claims in a manner understood by the corresponding service provider. Read more about claim management.
This topic contains the following sections.
Adding a service provider
- Log in to the Management Console.
- Navigate to the Main menu to access the Identity menu. Click Add under Service Providers.
- Fill in the Service Provider Name and provide a brief Description of the service provider. Only Service Provider Name is a required field.
Click Register to add the new service provider.
The Service Providers screen appears. Here you have the option of selecting if the service provider is a SaaS Application or not. The SaaS Application configuration defines which users you want to be able to log into your web application.
In the resulting screen, click the arrow buttons to expand the forms available to update.
Click here for details on how to configure claims
Claim mapping for a service provider involves mapping claims that are used by the service provider to the claims local to the WSO2 Identity Server. For the occasions where a service provider needs some information of the user from the Identity Server where the service provider authenticates, the claim mapping is useful. Once the user is authenticated, the service provider can use these received claim details to provide its service. See the Identity Server Architecture for more information on how claim mapping fits in to the overall scheme of things.
Claim mapping
- In the Claim Configuration form, s elect the claim mapping dialect by either choosing to use a local claim dialect or define your own custom claim dialect.
- If you choose to Use Local Claim Dialect, you need to fill in the following details.
- Fill in your requested claims by clicking the Add Claim URI button.
- Choose your Local Claim from the drop-down. Select whether this claim is a Mandatory Claim for the Service Provider using the checkbox.
- If you choose to Define Custom Claim Dialect, you need to do the following.
Add a custom claim URI by clicking on the Add Claim URI button. Clicking this button again enables you to map more claims.
Add the Service Provider Claim and choose the corresponding Local Claim from the drop-down. Select whether you want the claim to be a Requested Claim and whether this claim is a Mandatory Claim for the service provider, using the relevant checkboxes.
Select the Subject Claim URI and the Role Claim URI (for custom claims)from the drop-down. The claims you mapped are listed in the drop-down and you can choose among these claims.
Click here for details on how to configure roles and permissions
You can configure the roles and permissions of the service provider.
To configure roles and permissions for a service provider, do the following.
- Expand the Role/Permission Configuration section and the Permission and Role Mapping forms.
- Click the Add Permission button. Clicking this button again will enable you to add another entry.
Add the Service Provider Specific Permissions. You can delete entries by clicking the Delete button.
- Click the Add Role Mapping button. Clicking this button again will enable you to add another entry.
Enter the Local Role and the Service Provider Role. You can delete entries by clicking the Delete button.
Click here for details on how to configure inbound authentication
The responsibility of the inbound authenticator component is to identify and parse all the incoming authentication requests and then build the corresponding response. A given inbound authenticator has two parts:
- Request Processor
- Response Builder
For each protocol supported by the WSO2 Identity Server, there should be an inbound authenticator. The Identity Server includes inbound authenticators for SAML 2.0, OpenID Connect, OAuth 2.0, Kerberos KDC, WS-Trust STS and WS-Federation (passive). The responsibility of the SAML 2.0 request processor is to accept a SAML request from a service provider, validate the SAML request and then build a common object model understood by the authentication framework and handover the request to it. The responsibility of the SAML response builder is to accept a common object model from the authentication framework and build a SAML response out of it.
Both the request processors and the response builders are protocol aware, while the authentication framework is not coupled to any protocol. See Architecture for more information on the complete flow where inbound authenticators come into play.
You can configure the following for inbound authentication.
SAML2 Web SSO Configuration
- Expand the SAML2 Web SSO Configuration and click Configure.
- Select one of the following modes:
Manual configuration
- Select Manual Configuration and fill in the form that appears.
- Click Register.
The following points should be taken into consideration when filling the above New Service Provider form.
Field | Description | Sample value |
---|
Issuer | Specify the Issuer. This is the <saml:Issuer> element that contains the unique identifier of the service provider. This is also the issuer value specified in the SAML Authentication Request issued by the service provider. When configuring single-sign-on across Carbon servers, ensure that this value is equal to the ServiceProviderID value mentioned in the <IS_HOME>/repository/conf/security/authenticators.xml file of the relying party Carbon server. | travelocity.com |
Assertion Consumer URLs | Specify the Assertion Consumer URLs. This is the URL to which the browser should be redirected to after the authentication is successful. This is the Assertion Consumer Service (ACS) URL of the service provider. The identity provider redirects the SAML2 response to this ACS URL. However, if the SAML2 request is signed and SAML2 request contains the ACS URL, the Identity Server will honor the ACS URL of the SAML2 request. It should have this format: https://(host-name):(port)/acs. You can add multiple assertion consumer URLs for the service provider by entering the URL and clicking the Add button. | http://wso2is.local:8080/travelocity.com/home.jsp |
Default Assertion Consumer URL | Since there can be multiple assertion consumer URLs, you must define a Default Assertion Consumer URL in case you are unable to retrieve it from the authentication request. | http://wso2is.local:8080/travelocity.com/home.jsp |
NameID format | Specify the NameID format. This defines the name identifier formats supported by the identity provider. The service provider and identity provider usually communicate with each other regarding a specific subject. That subject should be identified through a Name-Identifier (NameID) , which should be in some format so that It is easy for the other party to identify it based on the format. Name identifiers are used to provide information regarding a user. | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
Certificate Alias | Select the Certificate Alias from the dropdown. This is used to validate the signature of SAML2 requests and is used to generate encryption. Basically the service provider’s certificate must be selected here. Note that this can also be the Identity Server tenant's public certificate in a scenario where you are doing a tenant specific configuration. | wso2carbon |
Response Signing Algorithm | Specifies the ‘SignatureMethod’ algorithm to be used in the ‘Signature’ element in POST binding. The default value can be configured in the <IS_HOME>/repository/conf/identity.xml file, in the SSOService element with SAMLDefaultSigningAlgorithmURI tag. If it is not provided the default algorithm is RSASHA 1, at URI ‘http://www.w3.org/2000/09/xmldsig#rsasha1'. | http://www.w3.org/2000/09/xmldsig#rsasha1 |
Response Digest Algorithm | Specifies the ‘DigestMethod’ algorithm to be used in the ‘Signature’ element in POST binding. The default value can be configured in the <IS_HOME>/repository/conf/identity.xml file, in the SSOService element with SAMLDefaultDigestAlgorithmURI tag. If it is not provided the default algorithm is SHA 1, at URI ‘http://www.w3.org/2000/09/xmldsig#sha1 ’. | http://www.w3.org/2000/09/xmldsig#sha1 |
Assertion Encryption Algorithm | The algorithm that the SAML2 assertion is encrypted. The default value can be configured in the <IS_HOME>/repository/conf/identity.xml file, in the SSOService element with SAMLDefaultAssertionEncryptionAlgorithm URI tag. The default is http://www.w3.org/2001/04/xmlenc#aes256-cbc. | www.w3.org/2001/04/xmlenc#aes256-cbc |
Key Encryption Algorithm | The algorithm that the SAML2 key is encrypted. The default value can be configured in the <IS_HOME>/repository/conf/identity.xml file, in the SSOService element with SAMLDefaultKeyEncryptionAlgorithm URI tag. The default algorithm is http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p |
Enable Response Signing | Select Enable Response Signing to sign the SAML2 Responses returned after the authentication process. | Selected |
Enable Signature Validation in Authentication Requests and Logout Requests | Select Enable Signature Validation in Authentication Requests and Logout Requests if you need this functionality configured. This specifies whether the identity provider must validate the signature of the SAML2 authentication request and the SAML2 logout request that are sent by the service provider. | Unselected |
Enable Assertion Encryption | Enable Assertion Encryption, if you wish to encrypt the assertion. | Unselected |
Enable Single Logout | Select Enable Single Logout so that all sessions are terminated once the user signs out from one server. If single logout is enabled, the identity provider sends logout requests to all service providers. Basically, the identity provider acts according to the single logout profile. If the service provider supports a different URL for logout, you can enter a SLO Response URL and SLO Request URL for logging out. These URLs indicate where the request and response should go to. If you do not specify this URL, the identity provider uses the Assertion Consumer Service (ACS) URL. | Selected |
Enable Attribute Profile | Select Enable Attribute Profile to enable this and add a claim by entering the claim link and clicking the Add Claim button. The Identity Server provides support for a basic attribute profile where the identity provider can include the user’s attributes in the SAML Assertions as part of the attribute statement. Once you select the checkbox to Include Attributes in the Response Always, the identity provider always includes the attribute values related to the selected claims in the SAML attribute statement. | Unselected |
Enable Audience Restriction | Select Enable Audience Restriction to restrict the audience. You may add audience members using the Audience text box and clicking the Add button. | Unselected |
Enable Recipient Validation | Select this if you require validation from the recipient of the response. | Unselected |
Enable IdP Initiated SSO | Select the Enable IdP Initiated SSO checkbox to enable this functionality. When this is enabled, the service provider is not required to send the SAML2 request. | Unselected |
Enable IdP Initiated SLO | Select the Enable IdP Initiated SLO checkbox to enable this functionality. You must specify the URL. | Unselected |
Enable Assertion Query Request Profile | Select the Enable Assertion Query Request Profile checkbox to query assertions that are persisted to the database when you login to the service provider application. For more information, see Querying SAML Assertions. | Unselected |
This option allows you to provide the configuration data required for configuring SAML2, by uploading a metadata .xml file instead of having to manually enter the values. This enables faster entry of configuration data and allows the user to use the same metadata XML file for multiple instances of entity configuration.
- Select Metadata File Configuration.
- Click Choose File, and select the .xml file containing the metadata for the service provider SAML configuration.
Click Upload.
Click here to view a sample of the metadata configuration file
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="sample.com">
<SPSSODescriptor
AuthnRequestsSigned="false"
WantAssertionsSigned="false"
protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
MIIC+jCCAmOgAwIBAgIJAParOnPwEkKjMA0GCSqGSIb3DQEBBQUAMIGKMQswCQYD
VQQGEwJMSzEQMA4GA1UECBMHV2VzdGVybjEQMA4GA1UEBxMHQ29sb21ibzEWMBQG
A1UEChMNU29mdHdhcmUgVmlldzERMA8GA1UECxMIVHJhaW5pbmcxLDAqBgNVBAMT
I1NvZnR3YXJlIFZpZXcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDcxMDA2
MzMwM1oXDTI0MDMxODA2MzMwM1owdjELMAkGA1UEBhMCTEsxEDAOBgNVBAgTB1dl
c3Rlcm4xEDAOBgNVBAcTB0NvbG9tYm8xFjAUBgNVBAoTDVNvZnR3YXJlIFZpZXcx
ETAPBgNVBAsTCFRyYWluaW5nMRgwFgYDVQQDEw9NeSBUZXN0IFNlcnZpY2UwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN6bi0llFz+R+93nLLK5BmnuF48tbODp
MBH7yGZ1/ESVUZoYm0GaPzg/ai3rX3r8BEr4TUrhhpKUKBpFxZvb2q+yREIeDEkD
bHJuyVdS6hvtfa89WMJtwc7gwYYkY8AoVJ94gU54GP2B6XyNpgDTXPd0d3aH/Zt6
69xGAVoe/0iPAgMBAAGjezB5MAkGA1UdEwQCMAAwHQYDVR0OBBYEFNAwSamhuJSw
XG0SJnWdIVF1PkW9MB8GA1UdIwQYMBaAFNa3YmhDO7BOwbUqmYU1k/U6p/UUMCwG
CWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTANBgkq
hkiG9w0BAQUFAAOBgQBwwC5H+U0a+ps4tDCicHQfC2SXRTgF7PlAu2rLfmJ7jyoD
X+lFEoWDUoE5qkTpMjsR1q/+2j9eTyi9xGj5sby4yFvmXf8jS5L6zMkkezSb6QAv
tSHcLfefKeidq6NDBJ8DhWHi/zvC9YbT0KkCToEgvCTBpRZgdSFxTJcUksqoFA==
</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
MIIC+jCCAmOgAwIBAgIJAParOnPwEkKjMA0GCSqGSIb3DQEBBQUAMIGKMQswCQYD
VQQGEwJMSzEQMA4GA1UECBMHV2VzdGVybjEQMA4GA1UEBxMHQ29sb21ibzEWMBQG
A1UEChMNU29mdHdhcmUgVmlldzERMA8GA1UECxMIVHJhaW5pbmcxLDAqBgNVBAMT
I1NvZnR3YXJlIFZpZXcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDcxMDA2
MzMwM1oXDTI0MDMxODA2MzMwM1owdjELMAkGA1UEBhMCTEsxEDAOBgNVBAgTB1dl
c3Rlcm4xEDAOBgNVBAcTB0NvbG9tYm8xFjAUBgNVBAoTDVNvZnR3YXJlIFZpZXcx
ETAPBgNVBAsTCFRyYWluaW5nMRgwFgYDVQQDEw9NeSBUZXN0IFNlcnZpY2UwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN6bi0llFz+R+93nLLK5BmnuF48tbODp
MBH7yGZ1/ESVUZoYm0GaPzg/ai3rX3r8BEr4TUrhhpKUKBpFxZvb2q+yREIeDEkD
bHJuyVdS6hvtfa89WMJtwc7gwYYkY8AoVJ94gU54GP2B6XyNpgDTXPd0d3aH/Zt6
69xGAVoe/0iPAgMBAAGjezB5MAkGA1UdEwQCMAAwHQYDVR0OBBYEFNAwSamhuJSw
XG0SJnWdIVF1PkW9MB8GA1UdIwQYMBaAFNa3YmhDO7BOwbUqmYU1k/U6p/UUMCwG
CWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTANBgkq
hkiG9w0BAQUFAAOBgQBwwC5H+U0a+ps4tDCicHQfC2SXRTgF7PlAu2rLfmJ7jyoD
X+lFEoWDUoE5qkTpMjsR1q/+2j9eTyi9xGj5sby4yFvmXf8jS5L6zMkkezSb6QAv
tSHcLfefKeidq6NDBJ8DhWHi/zvC9YbT0KkCToEgvCTBpRZgdSFxTJcUksqoFA==
</X509Certificate>
</X509Data>
</KeyInfo>
<EncryptionMethod Algorithm= "https://www.w3.org/2001/04/xmlenc#aes128-cbc">
<KeySize xmlns="https://www.w3.org/2001/04/xmlenc#">128</KeySize>
</EncryptionMethod>
</KeyDescriptor>
<SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https:/sample.com:3443/federation/SPSloRedirect/metaAlias/sp"
ResponseLocation="https://sample.com:3443/
federation/SPSloRedirect/metaAlias/sp"/>
<SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://sample.com:3443/federation/SPSloSoap/metaAlias/sp"/>
<ManageNameIDService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://sample.com:3443/federation/SPMniRedirect/metaAlias/sp"
ResponseLocation="https://sample.com:3443/federation/SPMniRedirect/metaAlias/sp"/>
<ManageNameIDService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https:/sample.com:3443/federation/SPMniSoap/metaAlias/sp"
ResponseLocation="https://sample.com:3443/federation/SPMniSoap/metaAlias/sp"/>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</NameIDFormat>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</NameIDFormat>
<AssertionConsumerService
isDefault="true"
index="0"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://sample.com:3443/federation/Consumer/metaAlias/sp"/>
<AssertionConsumerService
index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://sample.com:3443/federation/Consumer/metaAlias/sp"/>
</SPSSODescriptor>
</EntityDescriptor>
URL configuration
Metadata for a service provider may be published in a well known location via a URI. This option allows you to provide the configuration data required for configuring SAML2, by providing a URI(Ex: "https://spconfigs.com/sample-sp.xml") instead of having to manually enter the values. This enables faster entry of configuration data and allows the user to use the same metadata XML file for multiple instances of entity configuration.
- Select URL Configuration and enter the URL containing the service provider metadata.
- Click Upload.
See SAML 2.0 Web SSO for more information on SAML2 single-sign-on and see the following topics for samples of configuring single-sign-on using SAML2.
See Using the SAML2 Toolkit for support on debugging issues with SAML2 configurations.
OAuth/OpenID Connect Configuration
OAuth 2.0 has three main phases. They are; requesting an Authorization Grant, exchanging the Authorization Grant for an Access Token and accessing the resources using this Access Token. OpenID Connect is another identity layer on top of OAuth 2.0. OAuth applications can get authentication event information over the IDToken and can get the extra claims of the authenticated user from the OpenID Connect UserInfo endpoint.
To enable OAuth support for your client application, you must first register your application. Follow the instructions below to add a new application.
Let's get started to configure the service provider you created!
- Expand the Inbound Authentication Configuration section and then expand OAuth/OpenID Connect Configuration. Click Configure.
Fill in the form that appears. For the Allowed Grant Types you can disable the ones you do not require or wish to block.
When filling out the New Application form, the following details should be taken into consideration.
Field | Notes |
---|
OAuth Version | Selecting OAuth Version as 1.0a removes all the configurable Allowed Grant Types. This is because this version of OAuth does not support grant types. |
Callback Url | This is the exact location in the service provider's application where an access token would be sent. This is a required field (if the grant type is anything other than 'Code' or 'Implicit') and it is important to configure, as it is imperative that the service provider receives the access token. This is necessary for security purposes to ensure that the token is not compromised. |
Allowed Grant Types - The following are the grant types that are used to get the access token: |
Code | Entering the username and password required at the service provider will result in a code being generated. This code can be used to obtain the access token. For more information on this grant type, see this Authorization Code specification. |
Implicit | This is similar to the code grant type, but instead of generating a code, this directly provides the access token. For more information on this grant type, see this Implicit Grant specification. |
Password | This authenticates the user using the password provided and the access token is provided. For more information on this grant type, see this Resource Owner Password Credentials Grant specification. |
Client Credential | This is the grant type for the client key and client secret. If these two items are provided correctly by the service provider, the access token is sent. For more information on this grant type, see this Client Credentials specification. |
Refresh Token | This will enable the user to obtain an access token by using the refresh token once the originally provided access token is used up. For more information on this grant type, see this Refresh Token specification. |
SAML | This uses SAML assertion to obtain the access token. For more information on this grant type, see this SAML2 Bearer specification. |
IWA-NTLM | This is similar to the password grant type, but it is specific to Microsoft Windows users. |
urn:ietf:params:oauth:grant-type:jwt-bearer | This is a custom grant type. It uses a JWT token to obtain the access token. For more information about this grant type, see this JWT specification. |
PKCE Mandatory | Select this if you are using the Code grant type. PKCE is a recommended security measure used to mitigate a code interception attack. See Mitigating Authorization Code Interception Attacks for more information. |
Support PKCE 'Plain' Transform Algorithm | Select this if you are using PKCE. |
User Access Token Expiry Time, Application Access Token Expiry Time, Refresh Token Expiry Time | Set the validity period (in seconds) for User Access Token, Application Access Token, and Refresh Token. |
- Click Add. The following information is added for your service provider.
- OAuth Client Key - This is the client key of the service provider, which will be checked for authentication by the Identity Server before providing the access token.
- OAuth Client Secret - This is the client secret of the service provider, which will be checked for authentication by the Identity Server before providing the access token. Click the Show button to view the exact value of this.
- Actions -
Edit: Click to edit the OAuth/OpenID Connect Configurations
Revoke: Click to revoke (deactivate) the OAuth application. This action revokes all tokens issued for this application. In order to activate the application, you have to regenerate the consumer secret.
Regenerate Secret: Click to regenerate the secret key of the OAuth application.
Delete: Click to delete the OAuth/OpenID Connect Configurations
WS-Federation (Passive) Configuration
WSO2 Identity Server's passive security token service (Passive STS) is used as the WS-Federation implementation. The Passive STS is capable of issuing SAML 1.1 and 2.0 security tokens.
Configuring passive STS
- See here for details on adding a service provider.
Expand the Inbound Authentication Configuration followed by the WS-Federation (Passive) Configuration section and provide the following values.
- Expand the Claim Configuration section and map the relevant claims. See Configuring Claims for a Service Provider for more information.
- Click Update to save changes.
WS-Trust Security Token Service Configuration
WSO2 Identity Server uses the security token service (STS) as the WS-Trust implementation. The STS is capable of issuing SAML 1.1 and 2.0 security tokens and has a SOAP/XML API for token issuance. This API can be secured with the UserNameToken
or with any other WS-Security mechanism as explained below.
Securing the Security Token Service
According to the Trust Brokering model defined in the WS-Trust specification, the users should authenticate themselves to the STS before obtaining a token. STS may use this authentication information when constructing the security token. For example, STS may populate the required claims based on the user name provided by the subject. Therefore, the STS service needs to be secured.
STS is configured under the
Resident Identity Provider section of the WSO2 Identity Server
Management Console.
Follow the instructions below to secure the Security Token Service by logging into the management console.- Log in as an admin to access the management console.
- Configure the Resident Identity Provider. See here for more detailed information on how to do this.
- In the Resident Identity Provider page, expand the Inbound Authentication Configuration section along with the Security Token Service Configuration section.
- Click Apply Security Policy.
Select Yes in the Enable Security? dropdown and select a pre-configured security scenario according to your requirements. In this case, we will use UsernameToken under the Basic Scenarios section.
Click Next.
- Select ALL-USER-STORE-DOMAINS from the drop-down.
In the resulting page, select the role you created to grant permission to access secured service. In this example, the admin role is used. Next, click Finish.
- Click Ok on the confirmation dialog window that appears.
- Click Update to complete the process.
Now STS is configured and secured with a username and password. Only users with the Admin role can consume the service.
The next step is to add a service provider to consume the STS.
Adding a service provider for the STS client
Do the following steps if you are using a Holder of Key subject confirmation method. See Configuring STS for Obtaining Tokens with Holder-Of-Key Subject Confirmation for more information.
- See Configuring a Service Provider for details on adding a service provider.
- Expand the Inbound Authentication Configuration section and the WS-Trust Security Token Service Configuration section. Click Configure.
In the resulting screen, enter the trusted relying party's endpoint address that is the endpoint address of the Security Token Service. For more information, see Broker Trust Relationship with WSO2 Identity Server and upload the public certificate of the trusted relying party.
The endpoint must be used as the service URL
to which the token gets delivered by the STS client. Then select the public certificate imported. Tokens issued are encrypted using the public certificate of the trusted relying party. Therefore, the consumer who obtains this token, to invoke the RP service, won't be able to see the token.
Click Update to save the changes made to the service provider.
Run the STS client after configuring the service provider. See Running an STS Client to try out a sample STS client.
See Single Sign-On for details on configuring single sign-on for service provider using inbound authentication. See the following topics for samples of configuring single sign-on:
Click here for details on how to configure local and outbound authentication
The responsibility of the local authenticators is to authenticate the user with locally available credentials. This can be either username/password or even IWA (Integrated Windows Authentication) or FIDO (Fast IDentity Online). Local authenticators are decoupled from the Inbound Authenticators. Once the initial request is handed over to the authentication framework from an inbound authenticator, the authentication framework talks to the service provider configuration component to find the set of local authenticators registered with the service provider corresponding to the current authentication request.
Once the local authentication is successfully completed, the local authenticator will notify the framework. The framework will now decide no more authentication is needed and hand over the control to the corresponding response builder of the inbound authenticator. See Architecture for more information on this.
You can configure the following for local and outbound authentication.
- Expand Local & Outbound Authentication Configuration.
- Assert identity using mapped local subject identifier : This option will use the local subject identifier when asserting the identity.
- Always send back the authenticated list of identity providers : This option will send back the list of identity providers that the current user is authenticated by.
- Use tenant domain in local subject identifier : This option will append the tenant domain to the local subject identifier.
- Use user store domain in local subject identifier : This option will append the user store domain that the user resides in the local subject identifier.
- Enable Authorization: This option enables you to engage authorization policies for the service provider. For more information, see Configuring Access Control Policy for a Service Provider.
- Select the Authentication Type you require from the available options. This is a required field.
- If you choose Local Authentication, you need to select the local authentication option from the dropdown list.
- If you choose Federated Authentication, you need to select the identity provider from the dropdown list.
- If you choose Advanced Configurations, you can configure additional authentication steps and additional authentication options.
- There are two types of multi-factor authentication that can be configured here.
- Multi-step authentication: Click Add Authentication Step. Clicking this again will enable you to create another authentication step. Once this is done you can configure a Local or Federated authenticator for the step by selecting one from the dropdown and clicking Add Authenticator.
- Multi-option authentication: Click Add Authenticator to add either a Local or Federated authenticator after selecting it from the dropdown. Adding more than one of these within a single step enables multi-option authentication.
- Select whether to Use subject identifier from this step, Use attributes from this step or both. In the case of multiple steps, you can have only one step to use subject identifier from this step and one to use attributes from this step.
For example lets say, We configure 1st step as Facebook and enable Use subject identifier from this step. Then configure Google for 2nd step and enable Use attributes from this step. Once authentication is complete subject id will be taken from the Facebook claims and Google claims will be used as users attributes. - Click Add Authenticator to add a Local Authenticator. You can choose the type of authenticator using the dropdown. Clicking Add Authenticator again will enable you to add a second local authenticator. Basic authentication allows you to authenticate users from the enterprise user store.
- Click Add Authenticator to add a Federated Authenticator. You can choose the type of authenticator using the dropdown. Clicking Add Authenticator again will enable you to add a second federated authenticator.
- Click the Update button. This will return you to the previous screen with your newly configured authentication steps.
- Add a local authenticator under Request Path Authentication Configuration by clicking the Add button. Clicking the Add button again enables you to add another local authenticator. The two types of local authenticators available are as follows.
- OAuthRequestPathAuthenticator
- BasicAuthRequestPathAuthenticator
Look through the following for more details on the various authentication types.
Authentication Type | Details |
---|
Default | This is the default authenticator sequence for a configured service provider in the Identity Server. This sequence can be modified by updating following section in the <IS_HOME>/repository/conf/identity/application-authentication. xml file.
<Sequences>
<!-- Default Sequence. This is mandatory -->
<Sequence appId="default">
<Step order="1">
<Authenticator name="BasicAuthenticator"/>
</Step>
</Sequence>
</Sequences>
|
Local Authentication | In this case, Identity Server itself authenticate the user. There are three types of local authenticators OOTB in a fresh Identity Server pack. - The basic authenticator is used to authenticate the user using the credentials available in the Identity Server.
- IWA stands for Integrated Windows Authentication and involves automatically authenticating users using their Windows credentials.
- FIDO authenticator is a local authenticator that comes with the WSO2 Identity Server. This will handle FIDO authentication requests related key validation against stored keys, the public key, keyhandler, and the counter, attestation certificate of FIDO registered users.
|
Federated Authentication | In this case, Identity Server trust third-party Identity provider to perform the user authentication. These Identity providers use various protocols to transfer authentication/authorization related messages. Currently, the Identity Server only supports the following federated authenticators OOTB.- SAML2 Web SSO
- OAuth2/OpenID Connect
- WS-Federation (Passive)
- Facebook
- Microsoft (Hotmail, MSN, Live)
- Google
- SMS OTP
- Email OTP
- Twitter
- Yahoo
- IWA Kerberos
- Office365
|
Advanced Configuration | Advanced configurations enable you to add multiple options or steps in authentication. When multiple authentication steps exists, the user is authenticated based on each and every one of these steps. If only one step is added then the user is only authenticated based on the local and/or federated authenticators added in a single step. However, in the case of local and/or federated authenticators, the authentication happens based on any one of the available authenticators. |
Request path authenticators
A request path authenticator will get executed only if the initial authentication request brings the applicable set of credentials with it. See Request Path Authentication for more details.
Click here for details on how to configure inbound provisioning
See Inbound Provisioning for more information on inbound provisioning. To configure inbound provisioning for the service provider, follow the steps below.
Do the following to configure inbound provisioning.
- Expand the Inbound Provisioning Configuration section and expand the SCIM/SOAP Configuration form.
- Select the user store domain name from the drop down list to provision users and groups.
Click here for details on how to configure outbound provisioning
You might want to outbound provision users that self-register to your applications (service provider) to other entities, such as Google or Salesforce. This section guides you on how to configure outbound provisioning for a service provider.
Do the following to configure outbound provisioning.
- Expand the Outbound Provisioning Configuration. For this section to be configurable, you should already have added an identity provider and enabled an outbound provisioning connector (Google, Salesforce, SCIM, SPML, etc.).
Choose the identity provider you require from the drop-down and click
.
Click Update to save your changes.
- See Outbound Provisioning for more information on configuring user stores and service providers for outbound provisioning.
Click the Update button to update the details of the service provider.
Configuring a resident service provider
WSO2 Identity Server can mediate authentication requests between service providers and identity providers. At the same time, the Identity Server itself can act as a service provider and an identity provider. When it acts as a service provider it is known as the resident service provider.
The Identity Server mainly acts as a resident service provider while adding users to the system. You can enable provisioning configurations for the resident service provider. For example, if you try to add users to the system via the SCIM API (You must use a privileged local account to invoke the API to authenticate with HTTP Basic Authentication), the system will read the provisioning configurations from the resident service provider.
At the same time, if you want to configure outbound provisioning for any user management operation done via the management console, SOAP API or the SCIM API, you must configure outbound provisioning identity providers against the resident service provider. So, based on the outbound configuration, users added from the management console will also be provisioned to external systems like Salesforce and Google Apps.
Follow the instructions below to configure a resident service provider in the WSO2 Identity Server.
- Sign in. Enter your username and password to log on to the Management Console.
- Click Resident under the Service Providers on the Main tab.
- The Resident Service Provider page appears.
- Select the user store domain to provision users and groups for inbound authentication for SCIM or SOAP requests.
- For outbound provisioning configurations, select the identity provider from the dropdown list available and click the plus button to add this identity provider for provisioning. For an identity provider to appear on this list you have to add the identity provider in the Identity Server. The following are the names that would appear for each type of provisioning connector.
- Google provisioning connector - Google and googleapps
- Salesforce provisioning connector - salesforce.com and salesforce
- SCIM provisioning configuration - scim
- SPML provisioning configuration - spml
- Click Update.
Managing service providers
This topic provides instructions on how to manage service providers once they are created.
Viewing service providers
Follow the instructions below to view the list of service providers added in the WSO2 Identity Server.
- Sign in. Enter your username and password to log on to the Management Console.
- In the Main menu under the Identity section, click List under Service Providers. The list of service providers you added appears.
Editing service providers
Follow the instructions below to edit a service provider's details.
- Sign in. Enter your username and password to log on to the Management Console.
- In the Main menu under the Identity section, click List under Service Providers. The list of service providers you added appears.
- Locate the service provider you want to edit and click on the corresponding Edit link.
- You are directed to the edit screen. See here for details on the editable form.
Deleting service providers
Follow the instructions below to delete a service provider.
- Sign in. Enter your username and password to log on to the Management Console.
- In the Main menu under the Identity section, click List under Service Providers. The list of service providers you added appears.
- Locate the service provider you want to delete and click on the corresponding Delete link.
- Confirm your request in the WSO2 Carbon window. Click the Yes button.
See the following topics for information on configuring service providers using different specifications.
- See the Single Sign-On topic for details on how to configure a service provider for single sign-on using different specifications.
- See Identity Provisioning for information on configuring inbound and outbound provisioning with a service provider.
See the following topics to configure different applications as service providers in Identity Server.