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.
To register a service provider, do the following.- 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 WSO2 IS. Therefore, the certificate is used for the following scenarios:
- Configuring single sign-on - the certificate is used to validate the signature of the SAML2 authentication requests and the SAML2 logout requests that are sent by the service provider.
- Passing OIDC authentication request parameters - the certificate is used to:
- Encrypt the
id_token
sent to the service provider in the OIDC Authentication Response. - Validate the signed
Request
Object
sent in the OAuth2/OIDC Authorization Request.
- Encrypt the
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 keystone. 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.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.
You can configure the following for inbound authentication.
Removed Feature!
OpenID 2.0 has been removed from the base product in WSO2 Identity Server version 5.3.0 onwards as it is now an obsolete specification and has been superseded by OpenID Connect. Alternatively, we recommend that you use OpenID Connect.
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: