This blogpost is about positioning WSO2 API Manager and WSO2 Identity Server in a network infrastructure using a DMZ. I’ll also describe how to use various adminservices from the API Store to create users, request application tokens etc.
Finally I’ll touch the capability of WSO2 Identity server to convert a SAML assertion to an OAuth access token.
Design
A DMZ (demilitarized zone) is a sub-network that separates an internal local area network (LAN) from other untrusted networks, for instance the Internet. On this area, we are going to locate servers, resources and services to be accessible from the Internet. The internal LAN is going to be unreachable.
This design has two firewalls to protect, somehow, the DMZ and the backend, our LAN. This is a more secure approach since two devices would need to be compromised before an attacker could access the internal LAN. The first firewall, perimeter firewall, is configured to allow traffic to the DMZ only. The internal firewall is configured to allows traffic from the DMZ to the Intranet. This design uses a set of security controls on the DMZ and Intranet areas. For instance, a network intrusion detection and prevention systems located in the DMZ and on the Intranet.
As you can see on the picture, we have three main areas. The Internet, DMZ and the Intranet. Through the DMZ, we are going to allow final users to get access to the internal web services located on the Intranet. First of all, final user must have an user account on the WSO2API Store. With that tool the user have access to the web services related with an application. When the user subscribe to one application, it is going to gain access to a set of web services in relation with its role. In other words, web services are going to be grouped by, or protected by, user role. The subscribed user to an application is able to generate a set of key tokens to gain access to the web services. As security measure. They are consumer key and consumer secret. Those tokens can be used equally by another user that is has not been subscribed to the application. And always, the user must provide credentials (Password Grant Type).
An example of how to get access to the web services through the Access Token with User Credentials (Password Grant Type)
I summarize the process in a set of steps (WSO2 API Manager is installed on localhost):
1) To add a new user.
curl -X POST -b cookies http://localhost:9764/store/site/blocks/user/sign-up/ajax/user-add.jag -d ‘action=addUser&username=user1&password=test123&allFieldsValues=firstname|lastname|email’
2) Login.curl -X POST -c cookies http://localhost:9764/store/site/blocks/user/login/ajax/login.jag -d "action=login&username=user1&password=test123"
3) Add a new subscription. (orderSvc à DefaultApplication)
curl -X POST -b cookies http://localhost:9764/store/site/blocks/subscription/subscription-add/ajax/subscription-add.jag -d ‘action=addAPISubscription&name=orderSvc&version=v1&provider=admin&tier=Unlimited&applicationName=DefaultApplication’
4) Generate an Application Key with consumerKey and consumerSecret.curl -X POST -b cookies http://localhost:9764/store/site/blocks/subscription/subscription-add/ajax/subscription-add.jag -d 'action=generateApplicationKey&application=DefaultApplication&keytype=PRODUCTION&callbackUrl=&authorizedDomains=ALL&validityTime=360000'
{"error" : false, "data" : {"key" : {"validityTime" : 360000, "consumerKey" : "RKqjpS2pApm2ZOmZ1o54mz9HGTYa", "tokenDetails" : "{"scopes"":""[am_application_scope
