This documentation is for WSO2 Identity Server 5.0.0. View documentation for the latest release.
Adding an Identity Provider - Identity Server 5.0.0 - WSO2 Documentation
||
Skip to end of metadata
Go to start of metadata

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.
    • The Identity Provider Name should be unique.
    • The Home Realm Identifier is a standard value which will come with the communication from the Identity Provider. This is used as an identifier.
    • The Alias is the equivalent location specified in the identity provider.
  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. 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.

    To view these, 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 which includes a list of all the claims defined in the Identity Server.
      Basic Claim Configuration
    • If you choose to Define Custom Claim Dialect, do the following.
      Advanced Claim Configuration
      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.
      3. Select the User ID Claim URI from the dropdown which includes the list of identity provider claims you defined. This is used to uniquely identify the user by the identity provider.
      4. Select the Role ID Claim URI from the dropdown which includes the list of identity provider claims you defined. This is used to identify the role of the user by the identity provider.

    Configuring advanced claims

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

    • If you chose to Use Local Claim Dialect in the Basic Claim Configuration, do the following.
      1. For the Provisioning Claim Filter, select the claims which exist in the Identity Server from the dropdown list and click Add Claim. Clicking this button again will 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.

     Click here for details on how to configure roles

    You can configure the roles of the identity provider.

    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 Provider to the Identity Server.

     Click here for details on how to configure federated authenticators

    You can configure the following federated authenticators by expanding the required forms.

    In addition to this, you can create custom authenticators for more specific requirements.

    Configuring OpenID

    1. Expand the OpenID Configuration section.
    2. Fill in the following fields where relevant.

      FieldDescription
      Enable OpenIDSelecting this option will enable OpenId to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that OpenID is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.
      OpenID Server URLSpecify the OpenID Server URL. This is the URL to which the browser should be redirected after the authentication is successful. It should have this format: https://(host-name):(port)/acs.
      OpenID User ID LocationSelect whether the User ID is found in 'claimed_id' or if it is found among claims.
      Additional Query ParametersThis is necessary if you are connecting to another Identity Server or application. Sometimes extra parameters are required by this IS or application so these can be specified here.

    Configuring SAML2 Web SSO

    In a single sign on system there are two roles; Service Providers and Identity Providers. The important characteristic of a single sign on system is the pre-defined trust relationship between the service providers and the identity providers. Service providers trust the assertions issued by the identity providers and the identity providers issue assertions based on the results of authentication and authorization of principles which access services on the service provider's side.

    SAML 2.0 web browser-based single-sign-on profile is defined under the SAML 2.0 Profiles specification. SAML 2.0 provides five main specifications:

    • Core
    • Binding
    • Profile
    • Metadata
    • Conformance

    In a web browser-based SSO system, the flow can be started by the user either by attempting to access a service at the service provider, or by directly accessing the identity provider itself.

    1. Expand the SAML2 Web SSO Configuration form.
    2. Fill in the following fields where relevant.

      FieldDescription
      Enable SAML2 Web SSOSelecting this option enables SAML2 Web SSO to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that SAML2 Web SSO is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.
      Identity Provider Entity IdThis is basically the issuer of the response. It must be unique among identity providers.
      Service Provider Entity IdThis is the entity Id of the Identity Server. This is useful when differentiating between tenants.
      SSO URLThis is the URL to which the browser should be redirected after the authentication is successful. It should have this format: https://(host-name):(port)/acs.
      Enable Authentication Request SigningSelecting this checkbox enables you to sign the authentication request.
      Enable Assertion EncryptionThis is a security feature where you can encrypt the SAML2 Assertions returned after authentication.
      Enable Assertion Signing

      Select Enable Assertion Signing to sign the SAML2 Assertions returned after the authentication. SAML2 relying party components expect these assertions to be signed by the Identity Server.

      Enable LogoutSelect Enable Single Logout so that all sessions are terminated once the user signs out from one server.
      Logout URLYou can enter a custom Logout URL if required. If you do not enter anything here it will simply return to the SSO URL you specified.
      Enable Logout Request SigningSelecting this checkbox enables you to sign the logout request.
      Enable Authentication Response Signing

      Select Enable Authentication Response Signing to sign the SAML2 Responses returned after the authentication.

      SAML2 Web SSO User Id LocationSelect whether the User ID is found in 'Name Identifier' or if it is found among claims.
      Additional Query ParametersThis is necessary if you are connecting to another Identity Server or application. Sometimes extra parameters are required by this IS or application so these can be specified here.

    Configuring OAuth2/OpenID Connect

    1. Expand the OAuth2/OpenID Connect Configuration form.
    2. Fill in the following fields where relevant.

      FieldDescription
      Enable OAuth2/OpenIDConnectSelecting this option enables OAuth2/OpenID Connect to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that the OAuth2/OpenID Connect credentials are the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.
      Authentication Endpoint URLThis is the authentication URL for OAuth/OpenID Connect. This is a standard OAuth URL.
      Token Endpoint URLThis is the token endpoint URL. This is a standard OAuth URL.
      Client IdThe username of the web application. The Client Id and Client Secret are necessary as they will be used for authentication at the Authentication Endpoint and Token Endpoint.
      Client SecretThe password of the web application. Click the Show button to view the value you enter.
      OpenID Connect User ID LocationSelect whether the User ID is found in the 'sub' attribute or if it is found among claims.
      Additional Query ParametersThis is necessary if you are connecting to another Identity Server or application. Sometimes extra parameters are required by this IS or application so these can be specified here.

    Configuring WS-Federation (Passive)

    WS-Federation (Web Services Federation) describes the management and brokering of trust relationships and security token exchange across Web services and organizational boundaries. WS-Federation is a part of the larger WS-Security framework. For example, WS-Federation builds on the Security Token Service (STS) by providing mechanisms that facilitate interactions. In the WS-Federation Model an Identity Provider is a Security Token Service (STS). Service Providers depend on an Identity Provider or Security Token Service to do the user authentication. OAuth is an important protocol for IdP services as most major Web services are also identity providers, mainly through the use of OAuth. These Web services include Google, Facebook, Yahoo, AOL, Microsoft, PayPal, MySpace, and Flickr among many more. Furthermore, all major email providers offer OAuth IdP services.

    In most instances it is necessary to secure the Security Token Service. According the Trust Brokering model defined in the WS-Trust specification, the subject (user) should authenticate himself 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.

    1. Expand the WS-Federation (Passive) Configuration form.
    2. Fill in the following fields where relevant.

      FieldDescription
      Enable Passive STSSelecting this option enables Passive STS to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that Passive STS is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.
      Passive STS RealmThis is used as an identifier.
      Passive STS URLThis is the URL to which the browser should be redirected after the authentication is successful. It should have this format: https://(host-name):(port)/acs.
      Passive STS User ID LocationSelect whether the User ID is found in 'Name Identifier' or if it is found among claims. This specifies how the user is identified.
      Additional Query ParametersThis is necessary if you are connecting to another Identity Server or application. Sometimes extra parameters are required by this IS or application so these can be specified here.

    Configuring Facebook

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

      FieldDescription
      Enable Facebook AuthenticationSelecting this option enables Facebook to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that the Facebook credentials are the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.
      Client IdThis is the username from the Facebook app.
      Client SecretThis is the password from the Facebook app. Click the Show button to view the value you enter.

    Configuring Yahoo

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

      FieldDescription
      EnableSelecting this option enables Yahoo to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that Yahoo is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.

    Configuring Google

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

      FieldDescription
      EnableSelecting this option enables Google to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that Google is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.

    Configuring Microsoft Windows Live

    1. Expand the Microsoft (Hotmail, Msn, Live) Configuration form.
    2. Fill in the following fields where relevant.

      FieldDescription
      EnableSelecting this option enables Google to be used as an authenticator for users provisioned to the Identity Server.
      DefaultSelecting the Default checkbox signifies that Google is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.
      Client SecretThis is the password from the Microsoft Live application. Click the Show button to view the value you enter.
      Callback URLThis is the URL to which the browser should be redirected after the authentication is successful. It should have this format: https://(host-name):(port)/acs.
      Client IdThis is the username from the Microsoft Live application.

    App ID and App Secret are the values from the Facebook app which are used as the values for the Client Id and Client Secret respectively.

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

    You can configure Just-in-Time provisioning of the identity provider. With Just-in-Time provisioning, 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 don't need to manually create the user in the Identity Server. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort related to creating the account. Just-in-Time provisioning works with your identity provider to pass the correct user information to the Identity Server.

    • Selecting No provisioning from the available options disables Just-In-Time provisioning. This is selected by default.
    • Alternatively you could choose to always provision users to the user store domain. Select the user store domain name from the drop down list to provision users to the user store.

     Click here for details on how to configure outbound provisioning connectors

    You can configure outbound provisioning connectors.

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

    Configuring Google provisioning

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

      FieldDescription
      Enable ConnectorSelecting this enables identity provisioning through the Google domain.
      Google DomainThe name of the Google domain used to provision users to the Identity Server.
      Primary EmailSelect the primary email address from the dropdown. This must be a claim that is available and local in the Identity Server
      Given NameSelect the given name from the dropdown. This must be a claim that is available and local in the Identity Server
      Family NameSelect the family name from the dropdown. This must be a claim that is available and local in the Identity Server
      Service Account EmailThis email is used for authentication purposes.
      Private KeyBrowse and attach the private key from your local machine.
      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.
      Application NameThis is the name of the application which is used to represent the Google connector.

    Configuring Salesforce provisioning

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

      FieldDescription
      Enable ConnectorSelecting this enables identity provisioning through Salesforce.
      API versionThis is the version of the Salesforce API that is used for provisioning.
      Domain NameThis is the name of the Salesforce domain used to provision users.
      Client IDThis is the username of the client you are using to access Salesforce.
      Client SecretThis is the password of the client you are using to access Salesforce.
      UsernameThis is the Salesforce username.
      PasswordThis is the Salesforce password.

      About claim configuration for Salesforce

      The following claims must be configured when configuring Salesforce for outbound provisioning. See Configuring 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 which are initiated either by humans directly or by automated tasks.

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

      FieldDescription
      Enable ConnectorSelecting this enables identity provisioning through SCIM.
      UsernameThis is the username of the SCIM application.
      PasswordThis is the password of the SCIM application.
      User EndpointYou can configure users and groups in SCIM. This is the URL for the users.
      Group EndpointThis is the URL for the groups.
      User Store DomainThe user store that users are created.

    Configuring SPML provisioning

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

      FieldDescription
      Enable ConnectorSelecting this enables identity provisioning through SPML.
      UsernameThis is the username of the SPML application.
      PasswordThis is the password of the SPML application.
      SPML EndpointThis is the SPML URL.
      SPML ObjectClassThe ObjectClass for SPML. This value is required as it links with the ObjectClass in SPML which is used to provide data from the user store.

  6. Click Register to add the Identity Provider.
  • No labels