Test the integration

Having completed the integration steps, you can now test the setup using the cURL testing utility.

Note   You must have added a weblogic user to the API Gateway local user store as outlined in Prerequisites.

Assuming you are running API Gateway on a machine called apigateway on the default port of 8080, you can send a POST request to the authorization policy on API Gateway using HTTP basic authentication with the following command:

>curl  --user weblogic:weblogic --data "test=data" http://apigateway:8080/oes
User 'weblogic’ was authorized successfully!

You can see that the success message has been returned by API Gateway meaning that the weblogic user has been successfully authorized by OES to access the resource. A quick look at the API Gateway’s trace output shows the OES 11g Authorization filter making the successful authorization request for the MyApplication/MyResourceType/MyResource resource:

DEBUG   23/Oct/2012:15:28:45.183 [42687940] run circuit "OES Authorization"...
DEBUG   23/Oct/2012:15:28:45.183 [42687940] run filter [HTTP Basic Authentication] {
DEBUG   23/Oct/2012:15:28:45.183 [42687940] 	VordelRepository.checkCredentials: username=weblogic
DEBUG   23/Oct/2012:15:28:45.183 [42687940] 	Attempt to map incoming format Username to repository authZ format Username
DEBUG   23/Oct/2012:15:28:45.183 [42687940] } = 1, filter [HTTP Basic Authentication]
DEBUG   23/Oct/2012:15:28:45.183 [42687940] Filter [HTTP Basic Authentication] completes in 0 milliseconds.
DEBUG   23/Oct/2012:15:28:45.183 [42687940] run filter [11g Authorization] {
DEBUG   23/Oct/2012:15:28:45.183 [42687940] 	creating subject from 'weblogic'
DEBUG   23/Oct/2012:15:28:45.183 [42687940] 	checking 'POST' to resource: MyApplication/MyResourceType/MyResource
DEBUG   23/Oct/2012:15:28:45.185 [42687940] 	Request: {weblogic, POST, MyApplication/MyResourceType/MyResource}
Result: true
DEBUG   23/Oct/2012:15:28:45.185 [42687940] 	result from OES: true
DEBUG   23/Oct/2012:15:28:45.185 [42687940] 	no obligations in response
DEBUG   23/Oct/2012:15:28:45.185 [42687940] } = 1, filter [11g Authorization]
DEBUG   23/Oct/2012:15:28:45.185 [42687940] Filter [11g Authorization] completes in 2 milliseconds.

Now let's see what happens when you authenticate with a user that is present in the API Gateway's local user store, but that has not been configured with authorization rights in OES. To demonstrate this, you can send up a request using the credentials of the default API Gateway admin user:

>curl  --user admin:changeme --data "test=data" http://apigateway:8080/oes
User 'admin’ was NOT authorized to access the resource!

If you take a quick look at the API Gateway's trace output again, you can see that the 11g Authorization filter has blocked the authorization request:

DEBUG   23/Oct/2012:15:29:22.678 [41f67940] run circuit "OES Authorization"...
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] run filter [HTTP Basic Authentication] {
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] 	VordelRepository.checkCredentials: username=admin
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] 	Attempt to map incoming format Username to repository authZ format Username
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] } = 1, filter [HTTP Basic Authentication]
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] Filter [HTTP Basic Authentication] completes in 0 milliseconds.
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] run filter [11g Authorization] {
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] 	creating subject from 'admin'
DEBUG   23/Oct/2012:15:29:22.678 [41f67940] 	checking 'POST' to resource: MyApplication/MyResourceType/MyResource
DEBUG   23/Oct/2012:15:29:22.679 [41f67940] 	Request: {admin, POST, MyApplication/MyResourceType/MyResource}
Result: false
DEBUG   23/Oct/2012:15:29:22.679 [41f67940] 	result from OES: false
ERROR   23/Oct/2012:15:29:22.679 [41f67940] 	Failed to authZ to OES
DEBUG   23/Oct/2012:15:29:22.680 [41f67940] } = 0, filter [11g Authorization]
DEBUG   23/Oct/2012:15:29:22.680 [41f67940] Filter [11g Authorization] completes in 2 milliseconds.

Related Links