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. 
   
   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.
   

    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.
     
     
   • If you choose to Define Custom Claim Dialect, do the following.
     
     
     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.
        
     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.
        
     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.
      
   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.

      Field	Description
      Enable OpenID	Selecting this option will enable OpenId to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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 URL	Specify 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 Location	Select whether the User ID is found in 'claimed_id' or if it is found among claims.
      Additional Query Parameters	This 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.

      Field	Description
      Enable SAML2 Web SSO	Selecting this option enables SAML2 Web SSO to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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 Id	This is basically the issuer of the response. It must be unique among identity providers.
      Service Provider Entity Id	This is the entity Id of the Identity Server. This is useful when differentiating between tenants.
      SSO 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.
      Enable Authentication Request Signing	Selecting this checkbox enables you to sign the authentication request.
      Enable Assertion Encryption	This 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 Logout	Select Enable Single Logout so that all sessions are terminated once the user signs out from one server.
      Logout URL	You 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 Signing	Selecting 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 Location	Select whether the User ID is found in 'Name Identifier' or if it is found among claims.
      Additional Query Parameters	This 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.

      Field	Description
      Enable OAuth2/OpenIDConnect	Selecting this option enables OAuth2/OpenID Connect to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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 URL	This is the authentication URL for OAuth/OpenID Connect. This is a standard OAuth URL.
      Token Endpoint URL	This is the token endpoint URL. This is a standard OAuth URL.
      Client Id	The 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 Secret	The password of the web application. Click the Show button to view the value you enter.
      OpenID Connect User ID Location	Select whether the User ID is found in the 'sub' attribute or if it is found among claims.
      Additional Query Parameters	This 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.

      Field	Description
      Enable Passive STS	Selecting this option enables Passive STS to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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 Realm	This is used as an identifier.
      Passive STS 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.
      Passive STS User ID Location	Select 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 Parameters	This 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.

      Field	Description
      Enable Facebook Authentication	Selecting this option enables Facebook to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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 Id	This is the username from the Facebook app.
      Client Secret	This 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.

      Field	Description
      Enable	Selecting this option enables Yahoo to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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.

      Field	Description
      Enable	Selecting this option enables Google to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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.

      Field	Description
      Enable	Selecting this option enables Google to be used as an authenticator for users provisioned to the Identity Server.
      Default	Selecting 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 Secret	This is the password from the Microsoft Live application. Click the Show button to view the value you enter.
      Callback 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.
      Client Id	This 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.

      Field	Description
      Enable Connector	Selecting this enables identity provisioning through the Google domain.
      Google Domain	The name of the Google domain used to provision users to the Identity Server.
      Primary Email	Select the primary email address from the dropdown. This must be a claim that is available and local in the Identity Server
      Given Name	Select the given name from the dropdown. This must be a claim that is available and local in the Identity Server
      Family Name	Select the family name from the dropdown. This must be a claim that is available and local in the Identity Server
      Service Account Email	This email is used for authentication purposes.
      Private Key	Browse and attach the private key from your local machine.
      Administrator's Email	This 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 Name	This 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.

      Field	Description
      Enable Connector	Selecting this enables identity provisioning through Salesforce.
      API version	This is the version of the Salesforce API that is used for provisioning.
      Domain Name	This is the name of the Salesforce domain used to provision users.
      Client ID	This is the username of the client you are using to access Salesforce.
      Client Secret	This is the password of the client you are using to access Salesforce.
      Username	This is the Salesforce username.
      Password	This 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.

      Field	Description
      Enable Connector	Selecting this enables identity provisioning through SCIM.
      Username	This is the username of the SCIM application.
      Password	This is the password of the SCIM application.
      User Endpoint	You can configure users and groups in SCIM. This is the URL for the users.
      Group Endpoint	This is the URL for the groups.
      User Store Domain	The user store that users are created.

   Configuring SPML provisioning

   1. Expand the SPML Provisioning Configuration form.
      

   2. Fill in the following fields where relevant.

      Field	Description
      Enable Connector	Selecting this enables identity provisioning through SPML.
      Username	This is the username of the SPML application.
      Password	This is the password of the SPML application.
      SPML Endpoint	This is the SPML URL.
      SPML ObjectClass	The 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.