Monday, May 29, 2017

Configure Single Sign On (SSO) for a Web App Using WSO2 Identity Cloud and Consume APIs Published in WSO2 API Cloud Using JWT Bearer Grant Type

WSO2 Cloud provides comprehensive set of cloud solutions, This includes; Identity Cloud, API Cloud, Integration Cloud and Device Cloud. Identity Cloud provides security while API Cloud provides API Management solution (In near future identity Cloud is going to provide full set of IAM solutions, where at the moment (May 2017) it has only supports Single Sign On). In real world scenarios, application security and API security goes hand in hand where most of the time these web apps need to consume secured APIs.

In this post, we  are going to  look at how we can configure security for a web app with WSO2 Identity Cloud and that application needs to consume some OAuth protected APIs published in WSO2 API Cloud.

If you need to configure SSO for a application with WSO2 identity Cloud, you need to configure a service provider in Identity Cloud representing your application. Document https://docs.wso2.com/display/IdentityCloud/Tutorials explains the services provider configuration options in detail. If you are configuring SSO for a your own application (not a pre-defined app like Salesfoce, AWS etc), there are two main options provided, that you can select. Those are "Agent based SSO" and "Proxy based SSO". Post xxxxx explains what these two options are and when to choose which option, in detail.

Here, we are going to use Proxy based SSO option and configure SSO for a java web application. Once user is authenticated to access the application,   Identity Cloud sends a signed JSON Wen Token (JWT token) to the backend application. This JWT token can be used with JWT bearer grant type to get an access token from API Cloud to consume APIs publish there.

Before that, what is JWT bearer grant type;
JWT bearer grant type provides a way for client application to request an access token from OAuth server, using an existing proof of authentication in the form of a signed claims which was done by different Identity Provider. In our case, Identity Cloud is the JWT token provider while API Cloud is the one provide OAuth acess tokens.

Step 1: Configure Service Provider in Identity Cloud


i. Login to Identity Cloud admin portal : https://identity.cloud.wso2.com/admin
ii. Add New Application (Note: Select the "Proxy" as app type)





iii. Go to user-portal of tenant. (I'm using wso2org as the tenant, hence my user-portal is https://identity.cloud.wso2.com/user-portal/t/wso2org). This will list the application there and if you click on it, you can invoke it.  Note that application URL is not the real endpoint URL of application that used to invoke it. This is because, since we used "Proxy" option, Identity Cloud acts as a proxy for this app and gives a proxy URL (also called as gateway URL).




You need to block the direct app invocations using firewall rule or nginx rule to make sure, all users can access application only through Identity Gateway with the provided proxy URL. Following diagram explains what really happens there.





That's all we have to do to get SSO configured for your web application with Identity Cloud using proxy option. In summary, you login to Identity Cloud admin portal, register a new application (service provider) there by providing your web app endpoint url and provide a new url context to get gateway url constructed. Gateway do the SAML authentication part on behalf of application. 

Step 2 : Use JWT Token sends by Identity Cloud to backend and get a access token from API Cloud to invoke APIs


Backend web app needs to consume some APIs published in API Cloud. But the user authentication for web app happened from Identity Cloud, how can it get a access token from API Cloud ? We can use JWT Bearer Grant type for that, since Identity Cloud gives a JWT token after user authentication (for proxy type).

This JWT token should contains API Cloud as an audience, if it need to be consumed by API Cloud. 

i. Edit the service provider (application) which was registered in Identity Cloud and add API Cloud's key manager endpoint as an audience. 

Service provider configuring UI provided in Identity Cloud admin portal does not have option to add audiences for proxy type apps (which should be fixed in UI). Until that we need to login to the carbon management console of Identity Cloud and configure it.  
NOTE : Carbon mgt UIs of WSO2 Cloud are not exposed to everyone. You need to contact wso2 cloud support by filling form https://cloudmgt.cloud.wso2.com/cloudmgt/site/pages/contact-us.jag  to get carbon mgt UI access. 

In the Carbon UI, navigate to Main -> Service Providers -> List -> Click Edit of Service provider that you created.  Inbound Authentication configuration -> SAML -> Audience URLs  -> Add "https://keymanager.api.cloudstaging.wso2.com/oauth2/token" as audience and update the SP. Refer following image.




ii. Configure Identity Cloud as a trusted IdP in API Cloud.

API Cloud should trust Identity Cloud as a trusted IdP, if it needs to issue an access token using JWT token issued by Identity Cloud.  We need to login to Carbon UI of API Cloud's Key Manager and configure Identity Cloud as a trusted IdP. 
NOTE : You need to contact wso2 cloud support by filling form https://cloudmgt.cloud.wso2.com/cloudmgt/site/pages/contact-us.jag  to get carbon mgt UI access of API Cloud's Key Manager. 

Navigate to Main -> Identity Providers -> Add -> Give the IdP details and Save

Identity Provider Name : wso2.org/products/appm

Identity Provider Public Certificate : Need to upload your tenant's public certificate here. You can get this by login to the admin portal of Identity Cloud and Click on "Download IdP Metadata" option provided in application listing page. This metadata file contains public certificate as a one metadata. You can copy and save certificate into a separate file and upload here.

Refer following image for add IdP.



Following images shows how you can download tenant's public certificate from Identity Cloud to upload above.



Downloaded metadata file will looks something similar following. Copy the certificate into a separate file and upload.



We are done with all configurations.

Step 3 : How to read the value of JWT Token and use it to request access token from API Cloud ?


JWT Token is sent to the backend in the header of "X-JWT-Assertion". Backend application can read the value of this header to get the JWT token.

Following image shows a sample JWT token printed by backend application by reading "X-JWT-Assertion" header.



Then backend application can use this JWT token and call to API Cloud token endpoint to get an access token using JWT bearer grant type. Before that you can copy this JWT token and use curl or some other REST client and test it. 

curl -i -X POST -H "Authorization:Basic <YOUR_Base64Encoded(ConcumerKey:ClientSecreat)>" -k 
-d 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<YOUR_JWT_TOKEN_HERE>' 
-H 'Content-Type: application/x-www-form-urlencoded' https://gateway.api.cloud.wso2.com:443/token

This should provide you a oauth access token from API Cloud.

That's it !

Reference to sample web application code: https://github.com/dinusha-dilrukshi/wso2-integration-scenarios
This sample web app contains whole scenario described in this post. Try it too.

Sunday, May 28, 2017

What is Agent and Proxy Based SSO in WSO2 Identity Cloud ?

WSO2 Identity Cloud provides different options to easily configure Single Sign On (SSO) for your in-house enterprise applications and popular SaaS applications.

In the Service Provider configuration UI provided in Identity Cloud admin portal (https://identity.cloud.wso2.com/admin), you can see two options called "Agent" and "Proxy" that you need to select as App Type. Refer following image.



In this post we are going to look at a comparison of two options. So that it will help you to  decide which option is suitable for your app.

Agent based SSO (Agent Type)


  • Authentication SSO request/response should be handled by application itself. We called this type as "Agent based" because, you can write a common separate module (agent) that can be used by all your applications to handle authentication. 
eg: If you need to configure SSO for your application with SAML 2.0, then you should implement logic in your app to initiate SAML authentication request to Identity Cloud and Identity Cloud will send the authenticated SAML Response to application. Application should process this SAML response and identity the user and extract required user claims. (Note: With Service Provider Initiated SSO (SP init SSO), there is a way Identity Cloud to initialize the authentication request and application to handle only response sent by Identity Cloud )
  • Supports SAML 2.0, WS-Federation, OpenID connect standard protocols.
  • If the application already written to support these protocols, agent based option is the best fit. eg: Saleforce, AWS, Concur, GotoMeeting like SaaS application provides configuration options to configure federated authentication from IdPs using these standard protocols.
  • Following diagram illustrate how Agent Type app authentication works.

Proxy based SSO (Proxy Type)

  • Authentication SSO request/response are handled by the Identity Gateway. Application do not have to worry about it. Once user authenticated through Identity Gateway, it sends a signed JSON Web Token (JWT Token) containing authenticated user info to the backend app.
  • Application is given a proxy URL instead of real endpoint URL of app. Users should use this proxy URL instead of direct app endpoint to access it. 
  • If application does not have internal logic based on authenticated user, you can simply publish the app as a Proxy app in Identity Cloud and done with it. This will ensures users cannot access this app, without authenticating from Identity Cloud.
eg: wso2.com (http://wso2.com) site does not need user authentication to see the content of it. If we need to give access only to authenticated users, we can publish (define) this as a proxy app in Identity Cloud. This will give a new proxy URL and that need authentication to access the site. 
  • Most of the time applications need user information for application side session handling and execute some business logic. In this case application should process the JWT token sent by identity Gateway and extract the user information.
  • If you are trying to configure SSO for a well known SaaS app like Salesforce, AWS etc, then proxy type is not the option for it. Because, these apps expect authenticated user info and they do not have a way to process JWT token to get that info. Therefore mostly, Proxy Type can be used if you have control over modifying application source code.
  • Following diagram illustrate how proxy app type based app works.

  • Identity Gateway (Proxy based apps) capable in providing authorization as well to the application, not only authentication. 
eg: It has capability to define rules like this, 
- Application can be accessed only if authenticated user is having a particular role. 
- Some of the resources in application should be allowed for selected roles, while other resources in app can be accessed by all authenticated users. (This can be done using role based or defining a XACML policy for that resource) 
- Define throttling limits for resources based on number of access by user

NOTE: Identity Cloud admin portal does not provide UI for some of these gateway functionalities, even though identity Gateway has capability on handling them. UI will be improved to support them in future.
  • Following diagram shows the handler sequence that get executed when accessing a app as a proxy type app.



Hope this post will help you to select which app type is suitable for you from Agent and Proxy types.


Saturday, February 25, 2017

WSO2 Identity Cloud in nutshell


WSO2 Identity Cloud is the latest addition to  WSO2 public Cloud services.  Identity Cloud is hosted using WSO2 Identity Server which provides Identity and Access Management (IAM) solution. Initial launching of Identity Cloud has been focused on providing Single Sign On (SSO) solutions for organizations.

All most all the organizations use different applications. This cloud be in-house developed and hosted applications or Salesforce, Councur, AWS like SaaS applications. Having centralized authentication system for all the applications will increase the efficiency of maintaining systems, centralize monitoring and company security from system administrative perspective while it makes application users life easy. WSO2 Identity Cloud provides solution to configure SSO for these applications.

What are the features offered by WSO2 Identity Cloud ?


  • Single Sign On support with authentication standards - SAML-2.0, OpenID Connect, WS-Federation
     Single Sign On configurations for applications can be done using   SAML-2.0, OpenID Connect, WS-Federation protocols.   
            
  • Admin portal
    Portal provided for organization administrators to login and configure security for applications. Simplified UI is provided with minimum configurations. Pre-defined templates of security configurations are available by default for most popular SaaS apps. This list includes Salesforce, Concur, Zuora, GotoMeeting, Netsuite, AWS.
  • On-premise-user-store agent
    Organizations can connect local LDAP with Identity Cloud without sharing LDAP credentials with Identity Cloud and let users in organization LDAP to access applications with SSO.
  • Identity Gateway
    Act as a simple application proxy that intercepts application requests and applies security checks.
  • User portal
    User Portal provides a central location for the users of an organization to log in and discover applications in a central place, while applications can be accessed with single sign-on.

Why you should go for a Cloud solution ?


Depending on organization policies and requirements, you can either go for a on-premise deployment or Cloud Identity solution. If you have following concerns then selecting Cloud solution is the best fit for you.

  • Facilitating infrastructure - You don't have to spend money on additional infrastructure with the Cloud solution.
  • System Maintenance difficulties - If you do a on-premise deployment, then there should be a dedicated team allocated to ensure the availability of system and troubleshoot issues etc. But with the Cloud solution WSO2 Cloud team will take care of system availability. 
  • Timelines - Identity Cloud is a already tested, up and running solution. This will cut off the deployment finalizing and testing times that you should spend on a on-premise deployment.   
  • Cost - No cost involve for infrastructure or maintenance with the Cloud solution.

We hope WSO2 Identity Cloud can help building a Identity Management solution for your organization. Register and tryout for free -http://wso2.com/cloud/ and give us your feedback on bizdev@wso2.com or dev@wso2.org.

Wednesday, June 29, 2016

How to configure WSO2 App Manager with MySQL ?

All WSO2 products comes with H2 internal database/s by default. Any of these product can be configured with different databases other than the H2 DB. App Manager product contains several databases unique only to App Manager that is not common with other WSO2 products. If you are familiar with changing default database of any of WSO2 product, concept is similar for App Manager as well.  Anyway, here I'm explaining step by step, what each of these database in App Manager is doing and how we can configure them to use MySQL.

We have following five datasources defined in the {AppM_Home}/repository/conf/datasources/master-datasources.xml file.

[1] <name>jdbc/WSO2CarbonDB</name> - Use for registry data storage, user store, permission store
[2] <name>jdbc/WSO2AM_DB</name> - Use to store App details that created from App Manager
[3] <name>jdbc/WSO2AM_STATS_DB</name> - Stats storage. Needed only when Data Analytic Server is configured
[4] <name>jdbc/ES_Storage</name> - Use to store thumbnail/banner images of apps
[5] <name>jdbc/WSO2SocialDB</name> - Use to store comments and ratings added for apps by store users


This guide explains configuring App Manager standalone instance with MySQL DB. If it is a cluster deployment, there are some additional configurations required other than explains in this post.

Step 0: Login to the MySQL server and create 4 databases.
mysql> create database appm_regdb;
Query OK, 1 row affected (0.01 sec)

mysql> create database appm_appdb;
Query OK, 1 row affected (0.00 sec)

mysql> create database appm_esdb;
Query OK, 1 row affected (0.00 sec)

mysql> create database appm_socialdb;
Query OK, 1 row affected (0.00 sec)


Step 1: Change  datasources mentioned previously (other than the STATS_DB) as follows by pointing to above created MySQL databases. You need to replace the config with  valid database username/password.
Note that <defaultAutoCommit>false</defaultAutoCommit> property is mandatory for "jdbc/WSO2AM_DB" datasource.

File location: {AppM_Home}/repository/conf/datasources/master-datasources.xml

     <datasource>
            <name>WSO2_CARBON_DB</name>
            <description>The datasource used for registry and user manager</description>
            <jndiConfig>
                <name>jdbc/WSO2CarbonDB</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                   <url>jdbc:mysql://localhost:3306/appm_regdb</url>
                  <username>root</username>
                   <password>root</password>
                   <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                </configuration>
            </definition>
        </datasource>

        <datasource>
            <name>WSO2AM_DB</name>
            <description>The datasource used for APP Manager database</description>
            <jndiConfig>
                <name>jdbc/WSO2AM_DB</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                    <url>jdbc:mysql://localhost:3306/appm_appdb</url>
                    <username>root</username>
                    <password>root</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <defaultAutoCommit>false</defaultAutoCommit>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                </configuration>
            </definition>
        </datasource>

<datasource>
           <name>JAGH2</name>
           <description>The datasource used for by the Jaggery Storage Manager</description>
           <jndiConfig>
               <name>jdbc/ES_Storage</name>
           </jndiConfig>
           <definition type="RDBMS">
               <configuration>
                   <url>jdbc:mysql://localhost:3306/appm_esdb</url>
                   <username>root</username>
                   <password>root</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                   <maxActive>50</maxActive>
                   <maxWait>60000</maxWait>
               </configuration>
           </definition>
       </datasource>

<datasource>
            <name>WSO2_SOCIAL_DB</name>
            <description>The datasource used for social framework</description>
            <jndiConfig>
                <name>jdbc/WSO2SocialDB</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                    <url>jdbc:mysql://localhost:3306/appm_socialdb</url>
                    <username>root</username>
                    <password>root</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                </configuration>
            </definition>
        </datasource>

Step 2: Copy MySQL jdbc driver to {AppM_Home}/repository/components/lib directory

Step 3: Start the server with -Dsetup option. This will create the required tables in above four databases.
sh wso2server.sh -Dsetup

That's all.

Tuesday, April 26, 2016

How to use App Manager Business Owner functionality ?

WSO2 App Manager new release (1.2.0) has introduced capability to define business owner for each application. (AppM-1.2.0  is yet to be released by the time this blog post is writing and you could download nightly build from here and tryout until the release is done.)

1. How to define business owners ?

Login as a admin user to admin-dashboard by accessing following URL.
https://localhost:9443/admin-dashboard

This will give you UI similar to bellow where you can define new business owners.


Click on "Add Business Owner" option to add new business owners.


All created business owners are listed in UI as follows, which allows you to edit or delete from the list.




2. How to associate business owner to application ?

You can login to Publisher by accessing the following URL to create new app.
https://localhost:9443/publisher 

In the add new web app UI, you should be able to see page similar to following, where you can type and select the business owner for the app.



Once the required data is filled and app is ready to publish to store, change the app life-cycle state to 'published' to publish app into app store.



Once the app is published, users could access app through the App Store by accessing the following URL.
https://localhost:9443/store

App users can find the business owner details in the App Overview page as shown bellow.





If you are using REST APIs to create and publish the apps, following sample command would help.

These APIs are protected with OAuth and you need to generate a oauth token before invoking APIs.

Register a OAuth app and generates consumer key and secret key
Request:
curl -X POST -H "Content-Type: application/json" -H "Authorization: Basic YWRtaW46YWRtaW4=" -d  '{"clientName": "Demo_App", "grantType": "password refresh_token"}'  http://localhost:9763/api/appm/oauth/v1.0/register

Note: Authorization header should pass base64encoded(username:password) as the value in above request.

Response:
{"clientId":"1kaMrCWFr9NeT1VCfTxacI_Pu0sa","clientName":"Demo_App","callBackURL":null,"clientSecret":"YNkRA_30pwOZ6kNTIZC9B54p7LEa"}

Generate access token using above consumer/secret keys
Request:
curl -k -X POST -H "Authorization: Basic MWthTXJDV0ZyOU5lVDFWQ2ZUeGFjSV9QdTBzYTpZTmtSQV8zMHB3T1o2a05USVpDOUI1NHA3TEVh" -H "Content-Type: application/x-www-form-urlencoded" -d 'username=admin&password=admin&grant_type=password&scope=appm:read appm:administration appm:create appm:publish'  https://localhost:9443/oauth2/token

Note: Authorization header should pass base64encoded(clientId:clientSecret) as the value in above request.

Response:
{"access_token":"cc78ea5a2fa491ed23c05288f539b5f5","refresh_token":"3b203c859346a513bd3f94fc6bf202e4","scope":"appm:administration appm:create appm:publish appm:read","token_type":"Bearer","expires_in":3600}


Add new business owner
Request:
curl -X POST -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" -d '{"site": "http://wso2.com", "email": "beth@gmail.com", "description": "this is a test description", "name": "Beth", "properties": [{"isVisible": true,"value": "0112345678","key": "telephone"}]}' http://localhost:9763/api/appm/publisher/v1.1/administration/businessowner

Response:
{"id":1}


Create new App and define business owner as previously added business owner
curl -X POST -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" http://localhost:9763/api/appm/publisher/v1.1/apps/webapp -d '{
  "name": "TravelBooking",
  "version": "1.0.0",
  "isDefaultVersion":true,
  "displayName": "Travel Booking",
  "description": "description",
  "businessOwnerId":"1",
  "isSite": "false",
  "context": "/travel",
  "appUrL": "http://www.google.lk",
  "acsUrl": "",
  "transport": "http",
  "policyGroups": [
    {
      "policyGroupName": "policy1",
      "description": "Policy 1",
      "throttlingTier": "Unlimited",
      "userRoles": [
        "role1"
      ],
      "allowAnonymousAccess": "false"
    },
    {
      "policyGroupName": "policy2",
      "description": "Policy 2",
      "throttlingTier": "Gold",
      "userRoles": [
        "role2"
      ],
      "allowAnonymousAccess": "false"
    },
    {
      "policyGroupName": "policy3",
      "description": "Policy 3",
      "throttlingTier": "Unlimited",
      "userRoles": [
        "role3"
      ],
      "allowAnonymousAccess": "false"
    }
  ],
  "uriTemplates": [
    {
      "urlPattern": "/*",
      "httpVerb": "GET",
      "policyGroupName": "policy1"
    },
    {
      "urlPattern": "/*",
      "httpVerb": "POST",
      "policyGroupName": "policy2"
    },
    {
      "urlPattern": "/pattern1",
      "httpVerb": "POST",
      "policyGroupName": "policy3"
    }
  ]
}'

Response:
{"AppId": "78012b68-719d-4e14-a8b8-a899d41dc712"}


Change app lifecycle state to 'Published'
curl -X POST -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" http://localhost:9763/api/appm/publisher/v1.1/apps/webapp/change-lifecycle?appId=78012b68-719d-4e14-a8b8-a899d41dc712&action=Submit%20for%20Review

curl -X POST -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" http://localhost:9763/api/appm/publisher/v1.1/apps/webapp/change-lifecycle?appId=78012b68-719d-4e14-a8b8-a899d41dc712&action=Approve

curl -X POST -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" http://localhost:9763/api/appm/publisher/v1.1/apps/webapp/change-lifecycle?appId=78012b68-719d-4e14-a8b8-a899d41dc712&action=Publish

Retrieve App info in store
Request:
curl -X GET -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" http://localhost:9763/api/appm/store/v1.1/apps/webapp/id/78012b68-719d-4e14-a8b8-a899d41dc712

Response:
{"businessOwnerId":"1","isSite":"false","isDefaultVersion":true,"screenshots":[],"customProperties":[],"tags":[],"rating":0.0,"transport":["http"],"lifecycle":"WebAppLifeCycle","lifecycleState":"PUBLISHED","description":"description","version":"1.0.0","provider":"admin","name":"TravelBooking1","context":"/travel1","id":"78012b68-719d-4e14-a8b8-a899d41dc712","type":"webapp","displayName":"Travel Booking"}

Retrieve business owner details
Request:
curl -X GET -H "Authorization: Bearer cc78ea5a2fa491ed23c05288f539b5f5" -H "Content-Type: application/json" http://localhost:9763/api/appm/store/v1.1/businessowner/1

Response:
{"site":"http://wso2.com","email":"beth@gmail.com","description":"this is a test description","name":"Beth","properties":[{"isVisible":true,"value":"0112345678","key":"telephone"}],"id":1}

Tuesday, June 2, 2015

WSO2 App Manager 1.0.0 released

WSO2 App Manager is the very latest product added to WSO2 product stack.

App Manager can work as a Apps Store for web apps and mobile apps while providing whole set of other features.


  • Single sign on/ Single sign out between web apps
  • Role/permission based access control for web apps
  • Capability to configure federated authentication for web apps
  • Subscription maintenance in App Store
  • Commenting, Rating capabilities in App Store
  • Statistic monitoring for apps usage 

Above are the core features comes with App Manager. Have a look at App Manager product page to get an idea about whole other features and its capabilities.

http://wso2.com/products/app-manager/

Saturday, November 15, 2014

How to enable login to WSO2 API Manager Store using Facebook credentials

WSO2 Identity Server 5.0.0 release has provided several default federated authenticators like Google, Facebook, Yahoo. Even it's possible to write custom authenticator as well, in addition to default authenticators provided.

In this post we are going to demonstrate, how we can configure WSO2 API Manager with WSO2 Identity Server, so that users comes to API Store can use their Facebook account as well to login to API Store.

Step 1 : Configure SSO between API Store and API Publisher

First you need to configure SSO between publisher and store as mentioned in this document.

Step 2 : You need to have App Id and App secret key pair generated for a application registered in facebook developers site. This can be done by login to facebook developer site and creating a new app.

Step 3 :  Login to the Identity Server and register a IdP with Facebook authenticator

This can be done by navigating to Main -> Identity Providers -> Add. This will prompt the following window. In the "Federated Authenticators" section expand the "Facebook Configuration" and provide the details.

App Id and App Secrete generated in the step two maps to Client Id and Client Secret values asked in the form.



Step 4 : Go to the two service providers created in step-1 and associate the above created IdP to it.

This configuration is available under "Local & Outbound Authentication Configuration" section of the SP.


Step 5 : If you try to access store url (i.e: https://localhost:9443/store) , it should redirect to the facebook login page.

Step 6: In order to store users to capable in using their facebook account as a login, they need to follow this step and associate their facebook account to their user account in the API Store.

Identity Server has provided a dashboard which gives multiple features for users in maintaining their user accounts. Associating a social login for their account is a one option provided in this dashboard.

This dashboard can be accessed in the following url .
https://<IS_HOST>:<IS_PORT>/dashboard

eg: https://localhost:9444/dashboard

Note: If you are running Identiry Server with port offset, you need to do changes mentioned here, in order to get this dashboard working.

Login to the dashboard with API Store user account. It will give you a dashboard like follows.


Click on the "View details" button provided in "Social Login" gadget. In the prompt window, there is a option to "Associate Social Login".  Click on this and give your Facebook account id as follows.


Once account is registered, it will list down as follows.


That's all we have to configure . This user should be able to login to API Store using his facebook account now.

Note: This post explained , when there is already a user account is exist in the API Store , how these users can associate their facebook account to authenticate to API Store. If someone needs to enable API Store login for all facebook accounts without having user account in API Store, that should be done though a custom authenticator added to Identity Server. i.e Provision this user using JIT (Just In Time Provisioning) functionality provided in IdP and using custom authenticator associate "subscriber" role to this provisioned user.