II) Working Authentication, Authorization & Encryption in JAX-RS:

|-Ways of Securing our JAX-RS

|-1. Configuration (XML Configuration) Approach
|-2. Annotation Driven Approach
|-3. Programmatic Approach

1. Configuration Approach:
|-Configuring the Realms and Roles
|-Guidance to configure Security
|-Access the application with Security
|-Enforcing Encryption

To enable authentication, we need to configure in WEB-INF/web.xml deployment

descriptor of the WAR file our JAX-RS application is deployed in.
For example we wanted to secure our StockResource and for this we wanted to allow
only the "ADMIN" and "TRADER" only but not the "CUSTOMER" administrators that
means we should not allow any customers/client who are login to visiting our
application site rather we need to allow the customers who are already login and
registered with us as "TRADER" so that they only can get the Stock Price others cannot
be allowed.
"CUSTOMER" role can see the list of Stocks but these cannot get the stock price unless
until he register as TRADER.
That means we need to allow only ADMIN, TRADER roles only for Authentication.

@Path("/stock")
class StockResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/price/{stockName}")
public float getStockPrice(@PathParam("stockName") String stockName) {
return 232.5f;
}
}

Configuring the Realms and Roles:

Make sure that the application server started either from the Eclipse or from the
Command prompt
Access the application without security:
http://localhost:8082/1.1StockResourceSecurityUsingConfigApproachRESTEasy/rest/
stock/price/dell
In order to configuring security on a resource to secure a resource, we need to create
the users and roles in the JEE Container realms or LDAP groups in LDAP-Server.

D:\DB Reddy\Servers\jboss-as-7.1.1.Final\bin> add-user.bat (say Enter)

Step: 1
It will ask us to choose which type of user we wanted add
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
This is for Admin console users
b) Application User (application-users.properties)
This is for Application access users

So we need to create user to access our application

So type "b" in the console
Step: 2
It will ask us to create realm/group so say enter without typing anything so that in
default realm as ApplicationRealm so that user that we are going to create will added
to default realm.

Enter the details of the new user to add.

Realm (ApplicationRealm) : (Say Enter without typing anything)
Username : john
Password : welcome
Re-enter Password : welcome

What roles do you want this user to belong to? (Please enter a comma separated list,
or leave blank for none) : ADMIN (Enter)
Note:
Here if we enter ADMIN then we need to configure in web.xml also as "ADMIN" but
not as "admin" bcz roles are case sensitive.
Step: 3
About to add user 'jhon' for realm 'ApplicationRealm'
Is this correct yes/no? yes (type yes then press enter)
So this finishes the user "john" creation as "admin" role.

Similarly create one more user as

username= robin
password=welcome
with role as "TRADER" who is a customer to access the application.

similarly create one more user as

username= david
password=welcome
with role as "CUSTOMER" who is a customer to access the application.

Unless we have Authentication we will not enable the Authorization, Hence 1st we
need to enable the Authentication then Authorization.
Guidance to configure Security:
1. Configure the JAX-RS Runtime
2. Configure the type of Authentication Mechanism
3. Configure all of the security roles in the REST Application
4. Enable Role based mechanism of the users/groups in the roles
5. Restrict resources based on a given URL pattern, and Name the security roles that
are allowed access to the resources

web.xml
<web-app>

<!-- Step: 4 Enable Role Based Security which is vendor specific plugin-->
<context-param>
<param-name>resteasy.role.based.security</param-name>
<param-value>true</param-value>
</context-param>

<!-- Step: 1 -->

<!-- Configuring the RESTEasy Runtime -->
<servlet>
<servlet-name>resteasy</servlet-name>
<servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher
</servlet-class>
<init-param>
<param-name>resteasy.scan</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>resteasy.servlet.mapping.prefix</param-name>
<param-value>/rest</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>resteasy</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

<!-- Enable the Security for our JAX-RS-->

<!-- Step: 2 -->
<!-- Unless we have Authentication we cannot enable the Authentication
hence 1st we need to enable the Authentication then Autherization -->
<!-- Configure the type of Authentication Mechanism -->
<login-config>
<auth-method>BASIC</auth-method>
<!--We no need to give exact realm name rather we can give
rememberable name its our choice -->
<realm-name>ApplicationRealm (Default Realm)</realm-name>
</login-config>

<!-- Step: 3 -->

<!-- Configure all of the Authorization security
roles in the REST Application -->
<!-- Here we are configuring all the roles that we have -->
<security-role>
<role-name>ADMIN</role-name>
</security-role>
<security-role>
<role-name>CUSTOMER</role-name>
</security-role>
<security-role>
<role-name>TRADER</role-name>
</security-role>

<!-- Step: 5 -->

<!-- Impose security constraints on the Resources whom
we wanted apply the security -->
<security-constraint>
<web-resource-collection>
<!-- Any Name we can give -->
<web-resource-name>Stock Resource Trading</web-resource-name>
<!-- Any thing that come to this /rest/stock/* resources
apply the authentication -->
<url-pattern>/rest/stock/*</url-pattern>
<!-- If we didn't specify by default all HTTP methods are secured-->
<http-method>GET</http-method>
<!-- If we have PUT/DELETE/POST then we can configure
several multiple Http-method tags with Http methods -->
</web-resource-collection>

<!-- Apply the Autherization -->

<!-- On this StrockResource we are allowing ADMIN, TRADER to access the
but CUSTOMER role cannot access this Resource -->
<auth-constraint>
<role-name>ADMIN</role-name>
 <role-name>TRADER</role-name>
</auth-constraint>
</security-constraint>
<!-- If we want to configure multiple Resources then we can write
multiple <security-constraint> tags -->
</web-app>

The <login-config> element defines how we want our HTTP requests to be

authenticated for our entire deployment. The <auth-method> sub-element can be
BASIC, FORM, DIGEST, or CLIENT_CERT. These values correspond to Basic, Digest,
and Client Certificate Authentication, respectively.
The <login-config> element doesn’t turn on authentication. By default, any client can
access any URL provided by your web application with no constraints. To enforce
authentication, you must specify a URL pattern you want to secure. In our example,
we use the <url-pattern> element to specify that we want to secure the /stock/price
URL. The <http-method> element says that we only want to secure GET (If we want
configure POST/DELETE/PUT also) requests to this URL. If we leave out the <http-
method> element, all HTTP methods are secured. In our example, we only want to
secure GET requests, so we must define the <http-method> element.
Next, we have to specify which roles are allowed to GET to /stock/price. In the web.xml
file example, we define an <auth-constraint> element within a <security-constraint>.
This element has one or more <role-name> elements that define which roles are
allowed to access the defined constraint. In our example, applying this XML only gives
the ADMIN, TRADER roles permission to access the /stock/price URL.
If we set a <role-name> of * instead of ADMIN or something else then any user would
be able to access the constrained URL, but Authentication with a valid user would still
be required bcz we imposed the security. In other words, a <role-name> of * means
anybody who is able to log in can access the resource that means ADMIN, TRADER,
CUSTOMER all can access the application.
Finally, there's an additional bit of syntactic sugar we need to specify in web.xml. For
every <role-name> we use in our <auth-constraints> declarations, we must define a
corresponding <security-role> in the deployment descriptor.
There is a minor limitation when you’re declaring <security-constraints> for JAXRS
resources. The <url-pattern> element does not have as rich an expression syntax as
JAX-RS @Path annotation values. In fact, it is extremely limited. It supports only
simple wildcard matches via the * character. No regular expressions are supported.

For example:
/*
/stock/*
*.txt
The wildcard pattern can only be used at the end of a URL pattern or to match file
extensions. When used at the end of a URL pattern, the wildcard matches every
character in the incoming URL. For example, /foo/* would match any URL that starts
with /foo. To match file extensions, we need to use the format *.<suffix>. For
example, the *.txt pattern matches any URL that ends with .txt. No other uses of the
wildcard character are permitted in URL patterns.
For example, here are some illegal expressions:
/stock/*/price
/stock/*.txt

Access the application with Security:

Case: 1
Open the internet explorer only Bcz Once we access the Resource using Google
Chrome or ARC then again we it will not ask us to enter the credentials even though
we re-open bcz Chrome will stores the credentials hence again it will not ask for
credentials so we need to use Internet Explorer only.
If we POST req then use ARC/Postman to check multiple times.
http://localhost:8082/1.1StockResourceSecurityUsingConfigApproachRESTEasy/rest
/stock/price/dell
Give Authentication details as
usernae=john
password=welcome
So that we can access the application bcz john is ADMIN he can access the
StockResource bcz we configured in web.xml as ADMIN can access this Resource
Response:
Status: 200: OK
232.5

Close the internet explorer then again open the internet explorer
Case: 2
http://localhost:8082/1.1StockResourceSecurityUsingConfigApproachRESTEasy/rest
/stock/price/dell
Give Authentication details as
usernae=robin
password=welcome
So that we can access the application bcz robin is TRADER he can access the
StockResource bcz we configured in web.xml as TRADER can access this Resource
Response:
Status: 200: OK
232.5

Close the internet explorer then again open the internet explorer
Case: 3
http://localhost:8082/1.1StockResourceSecurityUsingConfigApproachRESTEasy/rest/
stock/price/dell
Give Authentication details as
username= david
password=welcome

We will get Error code as follows bcz he is an CUSTOMER so we didn't configure

CUSTOMER role to access this StrockResource hence it denies to access the application
Response:
HTTP Status 403 - Access to the requested resource has been denied type Status
report message Access to the requested resource has been denied
description Access to the specified resource
(Access to the requested resource has been denied) has been forbidden.
Enforcing Encryption:
By default, the servlet specification will not require access over HTTPS to any user
constraints you declare in your web.xml file. If you want to enforce HTTPS access for
these constraints, you can specify a <user-data-constraint> within your
<securityconstraint> definitions. Let’s modify our previous example to enforce HTTPS
with following configuration:
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

Web.xml
<web-app>
...
<security-constraint>
<web-resource-collection>
....
</web-resource-collection>
 <auth-constraint>
....
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</web-app>

So we have to do is declare a <transport-guarantee> element within a <user-

dataconstraint> that has a value of CONFIDENTIAL. If a user tries to access the URL
pattern with HTTP, she will be redirected to an HTTPS-based URL.
There are three possible values for the <transport-guarantee>:

Transport Description
NONE No encryption is required (http is fine)

CONFIDENTIAL The data must be encrypted, so that other parties cannot observe
the contents (e.g. enforce SSL)
INTEGRAL The data must be transported so that the data cannot be changed in
transit. Most servers use SSL for this value too, although in theory
you could use some hashing algorithm, as encryption is not required