We have made it easier to pay for WSO2 Cloud services (API, Integration, Device, and Identity). When we launched initially, monthly credit card payments were the only option we provided. Now we changed two things:
1. You can pay for a year ahead and save 10% of your subscription price:
2. And, if credit card is not something that your purchasing department likes, you can get a regular invoice and pay via a wire transfer instead:
Whatever is the WSO2 Cloud service of your choice, we would like you to be able to pay for it conveniently (and save money on the way!)
On the 3rd step of editing APIs in WSO2 API Cloud, you can set required authentication type for each resource:
We have already covered None as the option to allow invoking APIs without any authentication whatsoever. Today we will discuss the other options.
Application type means that the API will require OAuth tokens generated with client grant type. That grant type produces tokens specific to the subscription but not the end-users.
So if there is a web- or mobile application that subscribed to this API and it has multiple end-users, they will all be sharing the same token and the API backend will not “know” which end-user is invoking the API:
Application User type means that the API accepts OAuth tokens generated with password grant type. These tokens are specific to the end-user – they require not just the application key but also end-user’s username and password.
In this case, each end-user gets their own OAuth tokens even though they are using the same API subscription. API Gateway then generates a JWT token and uses it to pass application and user information to the API backend:
Application and Application User type means that both kinds of tokens are acceptable by the API.
OAuth scopes are a great way to segregate access to APIs and data. Combined with roles they can also be a powerful way to limit who gets access to what.
Let’s have a look at how you can implement scopes in WSO2 API Cloud.
Let’s start with a sample WorldBank API that has two resources: /countries and /indicators – both taking a code parameter:
We have it published in Developer Portal and can invoke either of them with no problem (as long as we are subscribed to the API):
Now let’s add two different scopes: one that would only give access to /countries and the other one that only gives access to /indicators.
To do this:
- Open the API for editing,
- Go to the third step (Manage),
- Scroll down and click the Add Scopes button:
- In the Define Scope dialog box, add the wb_geo scope for geographic data:
- Repeat the process to add wb_eco scope to the API.
- Now you can see both scopes available for the API. Click the + Scope button next to the /countries resource to assign its scope:
- Pick Geographic data for /countries and Economic data for /indicators:
- That’s it: we defined two new scopes and applied them to two different REST resources. Now click Save and Publish to update the API:
Generate scope-limited OAuth token
Now if you open the API in Developer Portal’s API Console, you will see two things: resources have notes about the scopes they need and attempts to invoke them with a regular OAuth key fail:
To generate an OAuth token with the OAuth scope included:
- In Developer Portal (a.k.a. API Store), click Applications,
- In the application list, click the application which you used to subscribe to the API (for example, DefaultApplication),
- Click the Production Keys tab,
- Scroll down to the Scopes section, select the scopes you want (for example, Geographic data), and click the Re-generate button (I picked “-1” as the validity period to have a non-expiring token):
- Now if you go back to the API, you can use the new token and successfully invoke the API:
If you want to limit scope access to particular groups of users, you follow the same procedure but this time also list the roles when adding your scopes. For example, in the screenshot below, I am limiting the wb_geo scope access to users in the researches role:
It has just become a lot easier to connect your corporate directory to web applications. WSO2 Identity Cloud’s agent now itself initiates its connection to the cloud and thus does not conflict with firewalls or require a DMZ placement.
WSO2 Identity Cloud is a simple way to enable single sign-on (SSO) from your LDAP to your and 3rd-party web applications, and also to give end-users a nice application catalog portal to locate and access their apps. When we originally launched the offering, the cloud service was initiating all connections to the LDAP agent, and thus you had to get the agent installed on a server visible on the internet. With today’s update, you no longer have to do that.
Now, you can install the agent on any server that can get to the internet itself. You can even take your own laptop with OpenLDAP running on it, and use that to evaluate our service.
All you have to do is:
- Go to WSO2 Identity Cloud,
- Sign in,
- Click the Connect your user store button,
- Click Connect my LDAP to Cloud to download the agent:
5. Follow the instructions on the agent download page to download the agent and configure it to connect to your LDAP and your cloud account:
6. Once the cloud starts seeing the agent, your users can start using their LDAP credentials to access the applications you hooked up to the cloud:
See detailed documentation here: Configuring an On-premise User Store