Adding and Configuring a Service Provider
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 into 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
Note: This section only describes how to add a service provider using the Management Console. Instead of adding a service provider via the management console, it is also possible to add a service provider using a configuration file as described here .
- 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.
The Service Provider Name should not contain any special characters except for fullstops (.), hyphens (-), underscores (_) and spaces.
Click Register to add the new service provider.
Note: When a service provider is created, it is assigned to a "APPLICATION" role (for instance, if you add Travelocity as the service provider, then the role will look like "Application/travelocity"). Users who wish to manage the created service provider should have this application role assigned. See Configuring Roles for guidance on how to do this.
The Service Providers screen appears. Paste the application's certificate to the Application Certificate field.
When is this certificate used
This certificate is used to validate the signatures of the signed requests from the application (service provider) to the Identity Server. Therefore, the certificate is used in below scenarios:
- Validate the signature of the SAML2 authentication requests and the SAML2 logout requests that are sent by the service provider
https://docs.wso2.com/display/IS530/Configuring+Single+Sign-On#ConfiguringSingleSign-On-Configuringtheserviceprovider
- Encrypt id_token sent to the service provider in OIDC Authentication Response
- Validate Signed Request Object sent in OAuth2/OIDC Authorization Request
https://docs.wso2.com/display/IS550/OIDC+Request+Object+Support+in+WSO2+Identity+Server
Format of the certificate
WSO2 IS expects the certificate to be in PEM format.
PEM is a Base64 encoded format, therefore contains ASCII character and easier to deal with rather than a binary encoded certificate.
How to obtain the PEM encoded certificate
The PEM content of a certificate in a JKS file, can be obtained by following the steps below:
1. Export the certificate from the keystore. The exported certificate will be in binary format.
keytool -export -keystore <keystore-path> -alias <alias-of-the-certificate> -file <path-of-the-expected-certificate-file> e.g. keytool -export -keystore wso2carbon.jks -alias wso2carbon -file wso2carbon.crt
2. Convert the above binary encoded certificate to a PEM encoded certificate
openssl x509 -inform der -in <path-of-binary-certificate> -out <path-of-expected-pem-content> e.g. openssl x509 -inform der -in wso2carbon.crt -out wso2carbon.pem
Note: You can paste the public certificate in to the given text area or upload file in PEM format. If the Application Certificate field is left blank, WSO2 IS is backward compatible and follows the previous implementation to locate the certificates in the keystore.
This means that if it is a SAML SSO flow, the certificate alias mentioned in SAML inbound authentication configuration is used when the certificate is not updated via the management console. If it is an OIDC request object signature validation, the certficate will be retrived from default keystore, aliase to consumer key of the auth application.- Validate the signature of the SAML2 authentication requests and the SAML2 logout requests that are sent by the service provider
Select if the service provider is a SaaS Application or not using the Saas Application checkbox. The SaaS Application configuration defines which users you want to be able to log into your web application.
Tip: By default, the SaaS Application check box is disabled, which means the web application is not shared among tenants so only users in the current tenant (the one you use to define the service provider) will be allowed to log into the web application. Alternatively, if you enabled the SaaS Application check box, that means this web application is shared among tenants so users from any tenant will be allowed to log into the web application. For example, if there are three tenants, namely TA, TB and TC and the service provider is registered and configured only in TA.
If the SaaS Application configuration is disabled, only users in TA are able to log into the web application.
If the SaaS Application configuration is enabled, all TA, TB, TC users are able to log into the web application.
- For more information on creating and managing tenants, see Creating and Managing Tenants.