This documentation is for WSO2 Identity Server 5.6.0 . View documentation for the latest release.

All docs This doc
||
Skip to end of metadata
Go to start of metadata

Introduction

An Identity Provider (IdP) is responsible for authenticating users and issuing identification information by using security tokens like SAML 2.0, OpenID Connect, OAuth 2.0 and WS-Trust. This is a favourable alternative to explicitly authenticating a user within a security realm.

The responsibility of the identity provider configuration is to represent external identity providers. These external identity providers can be Facebook, Yahoo, Google, Salesforce, Microsoft Windows Live, etc. If you want to authenticate users against these identity providers, then you must associate one or more federated authenticators with the WSO2 Identity Server. These identity providers support for different authentication protocols. For example, if you want to authenticate users against Salesforce, then you must associate the SAML 2.0 authenticator with the Salesforce identity provider, if you want to authenticate users against Yahoo, then you must associate the OpenID Connect authenticator with it. To make this process much easier, the Identity Server also comes with a set of more specific federated authenticators. For example, if you want to authenticate against Facebook, you do not need to configure OAuth 2.0 authenticator. Instead, you can directly use the Facebook federated authenticator.

Each identity provider configuration can also maintain a claim mapping. This is to map the identity provider's own set of claims to the Identity Server's claims. When the response from an external identity provider is received by the response processor component of the federated authenticator, before it hands over the control to the authentication framework, the response processor will create a name/value pair of user claims received in the response from the identity provider. These claims are specific to the external identity provider. Then it is the responsibility of the authentication framework to read the claim mapping configuration from the identity provider component and do the conversion. So, while inside the framework, all the user claim values will be in a common format.

So, in short, the WSO2 Identity Server allows you to add identity providers and specify various details that help you to link the identity provider to the Identity Server. So you must specify all information required to send the authentication requests and get a response back from the identity provider. This topic contains the following sections.

Adding an identity provider

Follow the instructions below to add a new identity provider.

  1. Sign in. Enter your username and password to log on to the Management Console
  2. Navigate to the Main menu to access the Identity menu. Click Add under Identity Providers.
  3. Fill in the details in the Basic Information section. 
    Adding an Identity Provider - Basic Information
    Note the following when filling the above form.

    FieldDescriptionSample Value
    Identity Provider Name

    The Identity Provider Name must be unique as it is used as the primary identifier of the identity provider.

    FacebookIdP
    Display Name

    The Display Name is used to identify the identity provider. If this is left blank, the Identity Provider Name is used. This is used in the login page when selecting the identity provider that you wish to use to log in to the service provider.

    Facebook
    DescriptionThe Description is added in the list of identity providers to provide more information on what the identity provider is. This is particularly useful in situations where there are many identity providers configured and a description is required to differentiate and identify them.This is the identity provider configuration for Facebook.
    Federation Hub Identity Provider

    Select the Federation Hub Identity Provider check-box to indicate if this points to an identity provider that acts as a federation hub. A federation hub is an identity provider that has multiple identity providers configured to it and can redirect users to the correct identity provider depending on their Home Realm identifier or their Identity Provider Name. When we have this check-box selected additional window will pop-up in the multi-option page in the first identity server to get the home realm identifier for the desired identity provider in the identity provider hub.

    Selected
    Home Realm Identifier

    The Home Realm Identifier  value can be specified in each federated IDP and can send the Home Realm Identifier value as the “fidp” query parameter (e.g., fidp=googleIdp) in the authentication request by the service provider. Then WSO2 Identity Server finds the IDP related to the “fidp” value and redirects the end user to the IDP directly rather than showing the SSO login page. By using this, you can avoid multi-option, in a multi-option scenario without redirecting to the multi-option page.

    FB
    Identity Provider Public Certificate

    The Identity Provider Public Certificate is the public certificate belonging to the identity provider. Uploading this is necessary to authenticate the response from the identity provider. See Using Asymmetric Encryption in the WSO2 Product Administration Guide for more information on how public keys work and how to sign these keys by a certification authority.

    This can be any certificate. If the identity provider is another Identity Server, this can be a wso2.crt file.

    Note: To create the Identity Provider Certificate, open your Command Line interface, traverse to the <IS_HOME>/repository/resources/security/ directory. Next you must execute the following command.

    keytool -export -alias wso2carbon -file wso2.crt -keystore wso2carbon.jks -storepass wso2carbon

    Once this command is run, the wso2.crt file is generated and can be found in the <IS_HOME>/repository/resources/security/ directory. Click Choose File and navigate to this location in order to obtain and upload this file.

    See Using Asymmetric Encryption in the WSO2 Product Administration Guide for more information.
    Alias

    The Alias is a value that has an equivalent value specified in the identity provider that we are configuring. This is required for authentication in some scenarios.

    http://localhost:9443/oauth2/token



     Click here for more information on the federation hub and the home realm identifier

    About the federation hub and the home realm identifier

    The federation hub has multiple identity providers configured to it. In a typical federation hub with multiple identity providers, each identity provider can have a unique home realm identifier that can be used to identify the identity provider you are logging into.

    So when a user tries to log in to a service provider following flow will happen,

    • The Identity Server which this service provider is configured on will find the required federated authenticator from the service provider configuration
    • If this Identity Provider configured as a federation hub, the user can specify the preferred identity provider in the federation hub using the multi-option page of the first Identity Server.
    • This information will pass with the authentication request to the federation hub.
    • When the request comes to the federation hub, it is sent to the identity provider that the user specifies from the first identity server. For instance, if the users prefer to use their Facebook credentials to log in, and Facebook is one of the identity providers configured in the federation hub, the user simply has to specify Facebook as the domain in the login screen of first Identity Server.

    When the Home Realm Identifier is not specified, you can either select the domain name from a dropdown in the login page, or you have to enter the domain value in a separate page prior to logging in. This can be configured as explained below.

    Open the <IS_HOME>/repository/conf/identity/application-authentication.xml file. The ProxyMode configuration allows the framework to operate in either smart mode or dumb mode. In smart mode, both local and federated authentication is supported, while in dumb mode, only federated authentication is supported. If dumb mode is configured here, you must provide the Home Realm Identifier, or you have to display a separate screen to the user to get it.

    If smart mode is configured, the default behavior applies, where you can enter a local username and password, or use federated authenticators for authentication.

    <ProxyMode>smart</ProxyMode>

     Click here for more information on the Alias

    About the Alias

    The Alias is used in the following authentication scenario.

    Here a SAML identity provider sends a SAML token to a web application for authentication. The SAML token has an audience restriction element that controls access and has a reference to the web application in order to access it. Using this token, the authentication takes place. Now, if the web application needs to access an API that is protected by OAuth 2.0, the same SAML token is sent to the token endpoint of the Identity Server. The Alias value you configure in the Identity Server is associated with this token endpoint. This alias value must be added to the audience restriction element of the SAML token. When this SAML token is sent to the Identity Server, you obtain an access token, which is used to access the API.

    So in order to configure this, you must add the SAML identity provider as an identity provider in the Identity Server using the instructions in this topic. When configuring this in the Identity Server, you must specify the token alias for this scenario to work. This indicates that any token coming from the SAML identity provider must have this alias value in the audience restriction element.

  4. Enter the Identity Provider Name and provide a brief Description of the identity provider. Only Identity Provider Name is a required field.
  5. Fill in the remaining details where applicable. Click the arrow buttons to expand the forms available to update.
    Adding Configurations for the Identity Provider

     Click here for details on how to configure claims

    Configuring claims for an identity provider involves mapping the claims available in the identity provider to claims that are local to the WSO2 Identity Server. This is done so that the Identity Server can identify the user attributes in the response sent from the identity provider. As an example, Facebook IdP will return authenticated user email as 'email' and identity server will map it to the 'http://wso2.org/claims/emailaddress' using the IdP claim mapping. See the Identity Server Architecture topic for more information on how claim mapping fits into the identity provider scenario.

    In the Claim Configuration form, there are two sub forms.

    • Basic claim configuration - This involves a straightforward mapping of the claim that is used on the identity provider side with the claims local to the Identity Server.
    • Advanced claim configuration - This involves more advanced mapping, where the mapped claims can have specific default values.

    Let's get started!

    To view the claim configuration section, expand the Claim Configuration form.

    Configuring basic claims

    Select the claim mapping dialect by either choosing to use a local claim dialect (i.e., a claim dialect local to the Identity Server) or define your own custom claim dialect (i.e., a claim dialect which exists in the identity provider that must be mapped to the Identity Server).

    • If you choose to Use Local Claim Dialect, select the claim you require from the User ID Claim URI dropdown that includes a list of all the claims defined in the Identity Server.

    • You can alternatively choose the Define Custom Claim Dialect option.

      For custom claim dialects, you must map the attributes of the user in the identity provider to the claims that are local to the Identity Server. These claims can be part of the response that is sent from the identity provider to the Identity Server. This can also be used when provisioning users from the Identity Server to an external identity provider. These claim values are sent as part of the outbound provisioning request. Do the following to configure this.
      1. Click the Add Claim Mapping button under Identity Provider Claim URIs. Clicking this button again enables you to perform more claim mapping.
      2. Map the value of the corresponding claim in the identity provider to the claim in the Identity Server. Click the Delete button to remove the claim mapping.

        PropertyDescriptionSample Value
        Identity Provider Claim URIClaim identifier used in the Identity Provider sideemailID
        Local Claim URIClaim identifier used in the WSO2 Identity Serverhttp://wso2.org/claims/emailaddress
      3. Select the User ID Claim URI from the dropdown that includes the list of identity provider claims you defined. This is used to uniquely identify the user in the response sent by the identity provider. This is also used to identify the user in provisioning requests.
      4. Select the Role ID Claim URI from the dropdown that includes the list of identity provider claims you defined. This is used to uniquely identify the role of the user in the response sent by the identity provider. This is also used to identify the role in provisioning requests.

    Configuring advanced claims

    You can make advanced claim configurations based on the basic configurations you have made.

     Click here for more information on when advanced claims are useful

    Provisioning scenario where advanced claims can be useful

    The following scenario encompasses two different scenarios where provisioning happens. For both these scenarios, advanced claims are very useful.

    In the above scenario, Google Apps is configured as an identity provider in the Identity Server and you would configure the Google provisioning connector for provisioning requests. When a user is added to the management console of the Identity Server, it is assumed in this scenario that the Identity Server acts as a resident service provider. This user is provisioned to Google Apps using the Google Apps identity provider configuration in the Identity Server. So when configuring claims for this scenario, we would have multiple local claim URIs associated to the user. For example, http://wso2.org/claims/emailaddress, http://wso2.org/claims/title, etc. From these claims, only some may be required to provision to Google Apps. This is where the Provisioning Claim Filter comes into play.

    The next scenario is for Just-In-Time (JIT) provisioning. Salesforce is the service provider and Facebook is the identity provider configured in the Identity Server. When JIT provisioning is configured in the service provider configuration, the user is provisioned to the user store configured in the Identity Server. What happens here is that the authentication request is sent from Salesforce to the Identity Server, which sends it along to Facebook for authentication. Once authentication is done, the response is sent back to the Identity Server, and this is when JIT provisioning happens. So basically, JIT provisioning happens while in the middle of an authentication flow.

    If the same user store is configured in the Google Apps identity provider configuration and JIT provisioning is enabled, the user is provisioned there as well. Once again, the Provisioning Claim Filter is vital to map only the required claims for the specific identity provider.

    Note: The provisioning can happen in a blocking mode or in a non-blocking mode. In the blocking mode, the authentication flow will be blocked until the provisioning finishes - while in the non-blocking mode, provisioning happens in a different thread. This can be specified in the service provider configuration.

    In both these scenarios, only some specific user attributes must be configured for provisioning as the claims are different for both Facebook and Google Apps and must be mapped to the claims in the Identity Server.

    Use the following instructions to configure advanced claims.

    • If you chose to Use Local Claim Dialect in the Basic Claim Configuration, do the following.
      1. When you send provisioning requests from the Identity Server to the external identity provider, it may not be necessary to send all the requests. So, you can use the Provisioning Claim Filter to filter out the user attributes you need to send from the other available attributes. To use the Provisioning Claim Filter, select the claims that exist in the Identity Server from the dropdown list and click Add Claim. Clicking this button again enables you to add a new entry.
        Advanced Claim for local claims
      2. Enter a Default Value for your claim. This value is the default value used when provisioning this claim. This value will be used in all instances of this field, e.g., if all users are from one organization, you can specify the name of the organization as a default value using this field. Clicking the Delete button will remove this advanced claim.
    • If you chose to Define Custom Claim Dialect in the Basic Claim Configuration, do the following.
      1. Select the Identity Provider Claim URI you defined from the dropdown list and click Add Claim. Clicking this button again will add a new entry.
        Advanced Claim for custom claims
      2. Enter a Default Value for your claim. This value is the default value used when provisioning this claim. This value will be used in all instances of this field, e.g., if all users are from one organization, you can specify the name of the organization as a default value using this field. Clicking the Delete button will remove this advanced claim.

    Mapping configured claims to an OpenID Connect claim

    Do this only,

    If your IDP is using OIDC claims and your newly added OIDC claims are not available in WSO2 OIDC claim dialect, you need to map those new OIDC claims to an existing unused OpenID Connect(OIDC) claim in WSO2 Identity Server. For that follow the below steps.

    Once you create a claim definition, you need to map that newly added claim to an OpenID Connect (OIDC) claim. To do this, do the following:

    1. Select Home -> Identity -> Claims -> List -> http://wso2.org/oidc/claim
    2. In the list select a claim that you do not use and map that to the newly added claim.

     Click here for details on how to configure roles

    This section provides instructions on how to configure roles for an identity provider. Role mapping needs to be done because roles in the Identity Server are different to the roles available in the identity provider that you are configuring. For example, if you are configuring Google Apps as an identity provider in the Identity Server, the admin role in the Identity Server needs to be mapped to an appropriate role in Google Apps so that the user will have the same role in Google Apps and the Identity Server.

    You can configure the roles of the identity provider by doing the following.

    1. Expand the Role Configuration section.
    2. To configure Identity Provider Roles, click Add Role Mapping. The following screen appears.
      Role Mapping
    3. Enter the Identity Provider Role and map it to the Local Role available in the Identity Server. See here for information on how the local role can be created in the Identity Server. Click the Delete button to remove the mapping.
    4. Enter the Identity Provider Provisioning Role. This configuration is very useful if you wish to only provision some users and not others. All users who are assigned to this role will be provisioned from the Identity Server to the identity provider. You can provision users that have multiple roles by specifying the roles in a comma-separated list.

       

     Click here for details on how to configure federated authenticators

    This topic includes information on how to configure federated authenticators in WSO2 Identity Server.

    Note: OpenID 2.0 has been removed from the base product as it is now an obsolete specification and has been superseded by OpenID Connect. We recommend using OpenID Connect instead.

    You can configure the following federated authenticators by expanding the Federated Authenticators section followed by the required subsections.

    More Federated Authenticators

    Some authenticators such as LinkedIn are not provided OOTB with WSO2 Identity Server but can be downloaded from the WSO2 store and plugged in to work with WSO2 IS. For more information on those authenticators and connectors, see the WSO2 Identity Server Connectors documentation.

     Click here for details on how to configure just-in-time provisioning

    Just-in-time provisioning is about how to provision users to the Identity Server at the time of federated authentication. A service provider initiates the authentication request, the user gets redirected to the Identity Server, and then the Identity Server redirects the user to an external identity provider for authentication. Just-in-time provisioning gets triggered in such a scenario when the Identity Server receives a positive authentication response from the external identity provider. The Identity Server will provision the user to its internal user store with the user claims from the authentication response.

    You configure JIT provisioning against an identity providernot against service providers. Whenever you associate an identity provider with a service provider for outbound authentication, if the JIT provisioning is enabled for that particular identity provider, then the users from the external identity provider will be provisioned into the Identity Server's internal user store. In the JIT provisioning configuration, you can also select the provisioning user store.

    JIT provisioning happens in the middle of an authentication flow. You can create users on the fly, without having to create user accounts in advance. For example, if you recently added a user to your application, you do not need to manually create the user in Identity Server or in the underlying user store. The provisioning can happen in a blocking mode or in a non-blocking mode. In the blocking mode, the authentication flow is blocked until the provisioning happens while in the non-blocking mode, provisioning happens in a different thread. If you want to allow a user to access your application only if the user is authenticated and provisioned, then you should use blocking mode.

    Configuring JIT provisioning for an identity provider

    To configure JIT provisioning for an identity provider, follow the steps below: 

    1. Start WSO2 Identity Server and access the Management Console via  https://localhost:9443/carbon/. For detailed instructions on starting WSO2 Identity Server, see Running the Product.
    2. Navigate to the Main menu to access the Identity menu. Click Add under Identity Providers.
    3. Click the Main tab on the Management Console, navigate to Identity Providers under the Identity menu, and then click Add. This displays the Add New Identity Provider screen.
    4. Enter appropriate values for all required fields in the Basic Information section. 

    5. Expand the Just-In-Time Provisioning section and select the JIT provisioning options based on your requirement.
      • If you want to disable JIT provisioning, select No Provisioning. This is selected by default.
      • If you want to always provision users to a selected user store domain, select Always provision to User Store Domain, and then select a required user store domain from the list of available user store domains. 

        Tip

        The user store domain that you see by default is the PRIMARY user store provided with WSO2 Identity Server. If you want to select a user store domain other than the default primary user store domain, you have to configure a user store of your preference so that it appears in the list for you to select. 

        If you apply the WUM update released on the 1st of August 2018 for WSO2 IS 5.6.0, and select Always provision to User Store Domain,

        • You can provision users to multiple user stores depending on the user name specified at the time of provisioning if you select As in username.

          If you select this option and do not specify the user name appropriately, the relevant user is provisioned to the PRIMARY user store domain. For example,

          • If you specify the user name as TEST.COM/user1, the user is provisioned to the TEST.COM user store domain.
          • If you specify the user name as user1, the user is provisioned to the PRIMARY user store domain.
        • You can select one of the following provisioning options depending on how you want to prompt users for relevant credentials at the time of JIT provisioning with a federated identity provider. The default selection is Provision silently.
          • Prompt for username, password and consent
          • Prompt for password and consent
          • Prompt for consent
          • Provision silently

        You can deploy a WUM update into production only if you have a paid subscription. If you do not have a paid subscription, you can use this functionality when the next version of WSO2 Identity Server is released.


        Provisioning claims should be compatible with the policies defined in the user store manager configuration. For example user name should match with UsernameJavaRegEx and
        RolenameJavaScriptRegEx in user store configuration.

    6. Click Register to add the identity provider.
    Related Topics

    For information on the JIT provisioning architecture, see Provisioning Architecture.

    For information on how to customize the user name and password provisioning UIs, see Customizing Just-In-Time Provisioning User Interfaces.

     Click here for details on how to configure outbound provisioning connectors

    You can configure the WSO2 Identity Server to provision users to external applications. See the Identity Server Architecture for more information on how this process fits into the overall picture

    You can configure outbound provisioning connectors by expanding the relevant section.

    In addition to this, you can also create custom connectors that are added to the list of outbound provisioning connectors once created.

    Configuring Google provisioning

    This configuration involves setting up the Identity Server to send provisioning requests to Google applications.

    Expand the Google Provisioning Configuration form and fill in the following fields where relevant. 

    FieldDescriptionSample value
    Enable ConnectorSelecting this enables identity provisioning through the Google domain.Selected
    Google DomainThe name of the Google domain used to provision users.mygoogledomain.com
    Primary EmailClaim URI which will be used to retrieve primary email address for the account to be created. This must be a claim that is available and local in the Identity Server. http://wso2.org/claims/emailaddress
    Given NameClaim URI which will be used to retrieve given name attribute for the user. This must be a claim that is available and local in the Identity Server. http://wso2.org/claims/givenname
    Family NameClaim URI which will be used to retrieve family name attribute for the user. This must be a claim that is available and local in the Identity Server. http://wso2.org/claims/lastname
    Service Account EmailThis email is used for authentication purposes.d343s86gf@developer.gserviceaccount.com
    Private KeyBrowse and attach the private key from your local machine. This is the PKCS12 private key generated at the service account creation<uploaded_file>
    Administrator's EmailThis is the email of the administrator who owns the service account in the Google Domain specified. Provisioning takes place using this email, so specifying this here serves as a means for authentication.om@mygoogledomain.com
    Application NameThis is the name of the application which is used to represent the Google connector.Domain
    Google Outbound Provisioning pattern

    This pattern is used to build the user id of Google domain. Combination of attributes UD (User Domain), UN (Username), TD (Tenant Domain) and IDP (Identity Provider) can be used to construct a valid pattern.

    This is a way to differentiate following scenarios:
    If there are several tenants and you must configure Google outbound provisioning for same Google domain in those tenants.
    If there are several user stores and you must configure the specific user store that needs to be provisioned.
    If there are multiple identity providers configured for same Google domain.

    {UD, UN, TD, IDP}
    Google Provisioning SeparatorThis is used to separate the values that you configure in the Google Outbound Provisioning pattern.For this, it is better to use a character that is not normally used in the user domain/username/tenant domain/idp name. For example: "_"


    Configuring Salesforce provisioning

    This configuration involves setting up the Identity Server to send provisioning requests to Salesforce. See Outbound Provisioning with Salesforce for more information on how this is configured from end to end.

    1. Expand the Salesforce Provisioning Configuration form.
    2. Fill in the following fields where relevant.

      FieldDescriptionSample value
      Enable ConnectorSelecting this enables identity provisioning through Salesforce.Selected
      API versionThis is the version of the Salesforce API that is used for provisioning. To obtain this, log into https://developer.salesforce.com/ and clickSetup. On the left navigation pane, click API under Develop. Generate one of those APIs to check the version.v32.0
      Domain NameThis is the name of the Salesforce domain used to provision users.  If you do not have a Salesforce domain, you can create a domain by logging into https://developer.salesforce.com/ and clicking Setup. On the left navigation pane, click My Domain under Domain Management. Make sure you enter the domain with an HTTPS prefix so that it resembles a URL.https://identityprovisioning-dev-ed.my.salesforce.com/
      Client IDThis is the username of the client you are using to access Salesforce. This Consumer Key value is obtained when configuring Salesforce. See Outbound Provisioning with Salesforce for more information.3MVG8123wefw763na2452683KJNsvrgKBwe4gyksKJ22f3g45
      Client SecretThis is the password of the client you are using to access Salesforce. This Consumer Secret value is obtained when configuring Salesforce. See Outbound Provisioning with Salesforce   for more information.<password>
      UsernameThis is the Salesforce username.samuel@wso2.com
      PasswordThis is the Salesforce password and must be entered along with the security token. So you would enter this in the following format: <password><security_token><password><security_token>
      OAuth2 Token Endpoint

      OAuth token endpoint URL of Salesforce.

      https://login.salesforce.com/services/oauth2/token
      Provisioning Pattern

      This pattern is used to build the user id of Salesforce domain. Combination of attributes UD (User Domain), UN (Username), TD (Tenant Domain) and IDP (Identity Provider) can be used to construct a valid pattern.

      This is a way to differentiate following scenarios:
      If there are several tenants and you must configure Salesforce outbound provisioning for same Salesforce domain in those tenants.
      If there are several user stores and you must configure the specific user store that needs to be provisioned.
      If there are multiple identity providers configured for same Salesforce domain.

      {UD, UN, TD, IDP}
      Provisioning SeparatorThis is used to separate the values that you configure in the Salesforce Outbound Provisioning pattern.For this, it is better to use a character that is not normally used in the user domain/username/tenant domain/idp name. For example: "_"
      Provisioning DomainThe user name of Salesforce is an email address. Here you can configure a specific domain name the username should have.yahoo.com

      About claim configuration for Salesforce

      The following claims must be configured when configuring Salesforce for outbound provisioning. See Outbound Provisioning with Salesforce for more information on how to do this.

      • Email
      • EmailEncodingKey
      • LanguageLocaleKey
      • LastName
      • LocaleSidKey
      • ProfileId
      • TimeZoneSidKey
      • Username
      • UserPermissionsCallCenterAutoLogin
      • UserPermissionsMarketingUser
      • UserPermissionsOfflineUser

    Configuring SCIM provisioning

    The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in the WSO2 Identity Server easier. Identity provisioning is a key aspect of any identity management solution and, as such, is very relevant to SCIM. In simple terms, it is to create, maintain and delete user accounts and related identities in one or more systems or applications in response to business processes that are initiated either by humans directly or by automated tasks.

    This configuration involves setting up the Identity Server to send provisioning requests to an external application that supports SCIM. See Outbound Provisioning with SCIM for more information on how this works in a typical scenario.

    1. Expand the SCIM Provisioning Configuration form.

      Fill in the following fields where relevant.

      FieldDescriptionSample value
      Enable ConnectorSelecting this enables identity provisioning through SCIM.Selected
      UsernameThis is the username of the SCIM application.Admin
      PasswordThis is the password of the SCIM application.<password>
      User EndpointThis is the SCIM endpoint of the users.https://localhost:9443/wso2/scim/Users
      Group EndpointThis is the SCIM endpoint of the groups.https://localhost:9443/wso2/scim/Groups
      User Store DomainThis is the user store that users are created. You can specify any user store connected to your identity provider.Domain
      Enable Password ProvisioningThis is to specify whether to send a default password, or the password sent in the SCIM request, to the server where it gets provisioned. In a scenario where the Identity Server is used as a proxy, and sending the password to some other server is not appropriate, the default password can be sent.Selected
      Default PasswordThe default password that must be sent.<password>

    Configuring SPML provisioning

    The Service Provisioning Markup Language (SPML) is the open standard for the integration and interoperation of service provisioning requests. The goal of SPML is to allow organizations to securely and quickly set up user interfaces for Web services and applications, by letting enterprise platforms such as Web portals, application servers, and service centers generate provisioning requests within and across organizations

    This configuration involves setting up the Identity Server to send provisioning requests to an external application that supports SPML. See Outbound Provisioning with SPML for more information on how this works in a typical scenario.

    1. Expand the SPML Provisioning Configuration form.
    2. Fill in the following fields where relevant.

      FieldDescriptionSample value
      Enable ConnectorSelecting this enables identity provisioning through SPML.Selected
      UsernameThis is the username of the SPML application.Configadmin
      PasswordThis is the password of the SPML application.<password>
      SPML EndpointThis is the SPML endpoint URL.http://localhost:9847/servelet/spml
      SPML ObjectClassThe ObjectClass for SPML. This value is required as it links with the ObjectClass in SPML that is used to provide data from the user store.spml2person
    Related Topics
    • See Outbound Provisioning for more information on configuring user stores and service providers for outbound provisioning.

  6. Click Register to add the Identity Provider.

Configuring a resident identity provider

Apart from mediating authentication requests between service providers and identity providers, WSO2 Identity Server can act as a service provider and an identity provider. When WSO2 Identity Server acts as an identity provider, it is called the resident identity provider

The resident identity provider configuration is helps service providers to send authentication or provisioning requests to WSO2 Identity Server via SAML, OpenID Connect, SCIM, or WS-Trust. For an example on how a resident identity provider is used to implement a security token service, see Configuring WS-Trust Security Token Service. The Resident identity provider configuration is a one-time configuration for a given tenant. It shows WSO2 Identity Server's metadata, e.g., endpoints. The resident identity provider configurations can be used to secure the WS-Trust endpoint with a security policy.

Follow the instructions below to configure a resident identity provider:

  1. Access the WSO2 Identity Server Management Console.
  2. Sign in as an admin user.
  3. On the Main tab, click Identity > Identity Providers > Resident

    The Resident Identity Provider page appears.

  4. Enter the required values as given below.

    FieldDescriptionSample Value
    Home Realm IdentifierThis is the domain name of the identity provider. If you do not enter a value here, when an authentication request comes to WSO2 Identity Server, a user will be prompted to specify a domain. You can enter multiple identifiers as a comma-separated list.localhost
    Idle Session Time OutThis is the duration in minutes for which an SSO session can be idle for. If WSO2 Identity Server does not receive any SSO authentication requests for the given duration, a session time out occurs. The default value is 15.15
    Remember Me Period

    This is the duration in weeks for which WSO2 Identity Server should remember an SSO session given that you have selected the Remember Me option in the WSO2 Identity Server login screen.

    The default value is 2 weeks.

    2
  5. You may configure inbound authentication by expanding the Inbound Authentication Configuration section. 
    1. To configure SAML2 configurations: 
      1. Click SAML2 Web SSO Configuration.

        The SAML2 Web SSO Configuration form appears.
      2. Enter the required values and learn the fixed values as given below. 

        FieldDescriptionSample/Fixed Value
        Identity Provider Entity IDThis is for tenant identification. The users who are provisioned through this tenant can be identified using this ID.localhost
        Destination URLs

        This defines the destination URL of the identity provider. This helps the service providers that connect to WSO2 Identity Server through a proxy server to locate WSO2 Identity Server.

        https://localhost:9443/samlsso
        SSO URL

        This is the SAML SSO endpoint of the identity provider.

        https://localhost:9443/samlsso
        Logout Url

        This is the identity provider's end point that accepts SAML logout requests.

        https://localhost:9443/samlsso
        Artifact Resolution URL

        This is the identity provider's endpoint that resolves SAML artifacts.

        https://localhost:9443/samlartresolve
        Metadata Validity PeriodThis is the duration for which the metadata will be valid for.60
        Enable metadata signingThis facilitates to enable or disable metadata signingfalse
    2. To configure OAuth2 or OIDC, click OAuth2/OpenID Connect Configuration.

      FieldDescriptionSample/Fixed Value
      Identity Provider Entity IDThis is for tenant identification. The users who are provisioned through this tenant can be identified using this ID.localhost
      Authorization Endpoint URL

      This is the identity provider's OAuth2/OpenID Connect authorization endpoint URL.

      https://localhost:9443/oauth2/authorize
      Token Endpoint URL

      This is the identity provider's token endpoint URL.

      https://localhost:9443/oauth2/token
      Token Revocation Endpoint URL

      This is the URL of the endpoint at which access tokens and refresh token are revoked.

      https://localhost:9443/oauth2/revoke
      Token Introspection Endpoint URL

      This is the URL of the endpoint at which OAuth tokens are validated.

      https://localhost:9443/oauth2/introspect
      User Info Endpoint URL

      This the URL of the endpoint through which user information can be retrieved. The information is gathered by passing an access token.

      https://localhost:9443/oauth2/userinfo
      Session iFrame Endpoint URL

      This the URL of the endpoint that provides an iframe to synchronize the session states between the client and the identity provider.

      https://localhost:9443/oidc/checksession
      Logout Endpoint URL

      This is the identity provider's endpoint that accepts SAML logout requests.

      https://localhost:9443/oidc/logout
      Web finger Endpoint URL

      This is the URL of the OpenID Connect token discovery endpoint at which WSO2 Identity Server's meta data are retrieved from.

      https://localhost:9443/.well-known/webfinger
      Discovery Endpoint URL

      This is the URL of the endpoint that is used to discover the end user's OpenID provider and obtain the information required to interact with the OpenID provider, e.g., OAuth 2 endpoint locations.

      https://localhost:9443/oauth2/oidcdiscovery
      Dynamic Client Registration Endpoint URL

      This is the URL of the endpoint at which OpenID Connect dynamic client registration takes places.

      https://localhost:9443/api/identity/oauth2/dcr/v1.1/register
      JWKS Endpoint URL

      This is the URL of the endpoint that returns WSO2 Identity Server's public key set in JSON Web Key Set (JWKS) format.

      https://localhost:9443/oauth2/jwks
    3. To secure the WS-Trust endpoint with a security policy, click Security Token Service Configuration section.

      For more information on security token service (STS), see Configuring WS-Trust Security Token Service.
  6. You may view the inbound provisioning configurations by clicking Inbound Provisioning Configuration section. 

    FieldDescriptionSample Value
    SCIM User Endpoint

    This is the identity provider's endpoint for SCIM user operations, e.g., creating and managing users.

    https://localhost:9443/wso2/scim/Users
    SCIM Group Endpoint

    This is the identity provider's endpoint for the SCIM user role operations, e.g., creating user roles, assigning user roles to users, and managing user roles.

    https://localhost:9443/wso2/scim/Groups
  7. Click Update

To modify the host name of the above-above mentioned URLs,

  1. open the carbon.xml file in the <IS_HOME>/repository/conf directory and update the value of the <HostName> parameter.

    <HostName>localhost</HostName>
  2. Open the identity.xml file in the <IS_HOME>/repository/conf/identity directory and update the vaule of the <IdentityPRoviderURL> parameter.

    <IdentityProviderURL>https://localhost:9443/samlsso</IdentityProviderURL>

    To ensure the client application is communicating with the right identity provider, WSO2 Identity Server compares the destination value in the SAML request with the URL in the above configuration.

Exporting SAML2 metadata of the resident IdP

To configure WSO2 Identity Server as a trusted identity provider in a service provider application, export the SAML2 metadata of the resident identity provider of WSO2 IS and import the metadata to the relevant service provider. 

Use one of the following approaches to do this. 

  1. Expand the Inbound Authentication Configuration section and then expand SAML2 Web SSO Configuration
  2. Click Download SAML2 metadata. A metadata.xml file will be downloaded on to your machine.
  3.  Import the metadata.xml file to the relevant service provider to configure WSO2 Identity Server as a trusted identity provider for your application. 

Managing identity providers

This section provides instructions on how to manage identity providers once they are created.

Viewing identity providers

Follow the instructions below to view the list of identity providers added in the WSO2 Identity Server.

  1. Sign in. Enter your username and password to log on to the Management Console.
  2. In the Main menu under the Identity section, click List under Identity Providers. The list of identity providers you added appears.

Editing identity providers

Follow the instructions below to edit an identity provider's details.

  1. Sign in. Enter your username and password to log on to the Management Console.
  2. In the Main menu under the Identity section, click List under Identity Providers. The list of identity providers you added appears.
  3. Locate the identity provider you want to edit and click on the corresponding Edit link.
  4. You are directed to the edit screen where you can modify the details you configured for the identity provider.

Deleting identity providers

Follow the instructions below to delete an identity provider.

  1. Sign in. Enter your username and password to log on to the Management Console.
  2. In the Main menu under the Identity section, click List under Identity Providers. The list of identity providers you added appears.
  3. Locate the identity provider you want to delete and click on the corresponding Delete link.
  4. Confirm your request in the WSO2 Carbon window. Click the Yes button.

Disabling/Enabling identity providers

Follow the instructions below to disable or enable an identity provider.

  1. Sign in. Enter your username and password to log on to the Management Console.
  2. In the Main menu under the Identity section, click List under Identity Providers. The list of identity providers you added appears.
  3. Locate the identity provider you want to delete and click on the corresponding Disable link to disable the identity provider. Clicking this link will change the link to Enable. To enable the identity provider again, click the Enable link.
  4. Click Ok on the confirmation form that appears when clicking Disable/Enable.
     
Related Topics

See the following topics for information on configuring service providers using different specifications.

See the following topics to configure different applications as service providers in Identity Server.

  • No labels