In the Datapower AAA represents three security processes -
Authentication, Authorization and Auditing
An AAA policy identifies a set of resources and procedures that
determine whether a requesting client is granted access to a specific service,
file, or document. AAA policies can be considered a type of filter, for they
accept or deny a specific client request.
AAA policies are powerful and flexible. They support a range of
authentication and authorization mechanisms.
Authentication - verifies the identity of the request client.
Authorization - determines whether the client has access to the
requested resource.
Auditing – keeps records of any attempts to access resources.
Example: We will create a MPGW which will allow client to send JSON
request with Authorization header and allow client to access backend on successful authorization, in our
case we will skip backend and return the same request which client sent.
Create a MPGW
Click on Multi-Protocol Gateway and click on Add button
Assign a name to the MPG service.
Choose dynamic-backend from Type field.
Creation of Policy
After clicking on + of Multi-Protocol Gateway Policy you will get policy as below. Assign a name to a policy. Create a new rule, select the rule direction as “Client to Server” and configure the “Match” action as follows.
Creation of Rules
Double click on match action then “Configure
Match Action” window appears Drop down the Matching Rule, you will get all the
list of already existed “matching rules” and pick one of them. We are using all
which will match all the incoming URI’s
Creation of Policy
After clicking on + of Multi-Protocol Gateway Policy you will get policy as below. Assign a name to a policy. Create a new rule, select the rule direction as “Client to Server” and configure the “Match” action as follows.
Creation of Rules
Double click on match action then “Configure
Match Action” window appears Drop down the Matching Rule, you will get all the
list of already existed “matching rules” and pick one of them. We are using all
which will match all the incoming URI’s
Adding a AAA Action
Now drag and drop the “AAA action” on to the “client to server” rule as shown below.
Double click on “AAA action” to configure it.
Adding a AAA Action
Now drag and drop the “AAA action” on to the “client to server” rule as shown below.
Double click on “AAA action” to configure it.
After double clicking on AAA action you redirect to bellow page. To create new AAA policy click on symbol from “AAA policy” field.
Name the policy. For this exercise let it be “AAA_demo”.
Click on create.
Extracting User Identity
After clicking on create you will get page like bellow. Choose “HTTP
Authentication header” from the all given checks in identification methods and
click on “next”.
Authenticating the user
Choose “use AAA information file” among
the methods given. In “URL” set path to local and choose “AAAinfo.xml” from the
list
Click on Next
Extracting the Resource
From the Resource
Identification Methods field select “URL sent by client” in given checks and
click on next
Authorizing the Request
Select “Allow any authenticated client”
from the all given options
Leave all other option to default in next page and commit.
Drag and
drop the “advanced action” on to the “client to server rule”.
Double click on
“advanced action” to configure it.
In order to set dynamic-backend choose “Set variable” method in
operation and click on next.
Click on “var Builder” in “service variable” field.
In set
variable field click on “service variable” then you can see a list of variable
names like below. From the list of variable select
“var://service//mpg/skip-backside”.
We will add Convert Query Params to XML to client to server rule which
will look as below.
Final Step: Configure HTTP FSH handler by providing the local IP
address and port and test the service.Also configure the request and response
type to NON-XML (As we are using JSON)
Note:
We used Convert Query Prams to XML action as AAA policy only
understands XML and our input request is JSON.
So we need to do the
JSON->XML conversion before AAA.
As we need to send same JSON received from client to backend and we
are not using the request content anywhere in our flow. But the output of
Convert Query Prams to XML will be JSONX, so we will set the Input to Set
Variable action to INPUT context variable which contains the original request received.
Note: To view the JSON request (NON-XML) passed from client in
Probe Go to Rule we created for the service in from Objects screen as below and
turn on the Non-XML Processing
Leave all other option to default in next page and commit.
Drag and drop the “advanced action” on to the “client to server rule”.
You example is not working in IBM DataPower Gateway IDG.2018.4.1.0 , for json/rest result will be "1".
ReplyDelete