A Real Case with WAS Security

This case worked under RSA 7.0 and WAS 6.1.

In the application, it defined two roles, tliu:passw0rd:101:101:Thomas Liu and authenticated_user. Only users with administrator role can access administrator pages and carry out administrator functions. Any users authenticated with a pair of user id and password can access general pages and carry out general functions.

In the application.xml file of the EAR project, two security-roles were defined.

[security-role id="admin"]
[role-name]administrator[/role-name]
[/security-role]
[security-role id="user"]
[role-name]authenticated_user[/role-name]
[/security-role]

In the ibm-application-bnd.xml file of the EAR project, one authorization table with two authorizations was defined.

[authorizationTable xmi:id="AuthorizationTable_1126620398213"]
[authorizations xmi:id="RoleAssignment_1126807102767"]
[specialSubjects
xmi:type="applicationbnd:AllAuthenticatedUsers"
xmi:id="AllAuthenticatedUsers_1140011292114"
name="AllAuthenticatedUsers" /]
[role
href="META-INF/application.xml#user" /]
[/authorizations]
[authorizations xmi:id="RoleAssignment_1140011292114"]
[role
href="META-INF/application.xml#admin" /]
[groups xmi:id="Group_1140011292114" name="ceadmin" /]
[/authorizations]
[/authorizationTable]

In the web.xml file of the web project, two security-constraint, one login-config, and two security-role were defined.

[security-constraint]
[display-name]Administrators Constraint[/display-name]
[web-resource-collection]
[web-resource-name](Administrator Web Resource Collection)[/web-resource-name]
[description][/description]
[url-pattern]/admin/*[/url-pattern]
[http-method]GET[/http-method]
[http-method]PUT[/http-method]
[http-method]HEAD[/http-method]
[http-method]DELETE[/http-method]
[http-method]OPTIONS[/http-method]
[/web-resource-collection]
[auth-constraint]
[description][/description]
[role-name]administrator[/role-name]
[/auth-constraint]
[user-data-constraint]
[transport-guarantee]NONE[/transport-guarantee]
[/user-data-constraint]
[/security-constraint]
[security-constraint]
[web-resource-collection]
[web-resource-name](Users Web Resource Collection)[/web-resource-name]
[description][/description]
[url-pattern]/document/*[/url-pattern]
[http-method]GET[/http-method]
[http-method]PUT[/http-method]
[http-method]HEAD[/http-method]
[http-method]POST[/http-method]
[http-method]DELETE[/http-method]
[/web-resource-collection]
[auth-constraint]
[description][/description]
[role-name]authenticated_user[/role-name]
[/auth-constraint]
[user-data-constraint]
[transport-guarantee]NONE[/transport-guarantee]
[/user-data-constraint]
[/security-constraint]
[login-config]
[auth-method]FORM[/auth-method]
[form-login-config]
[form-login-page]/login.do[/form-login-page]
[form-error-page]/login_error.do[/form-error-page]
[/form-login-config]
[/login-config]
[security-role]
[description][/description]
[role-name]administrator[/role-name]
[/security-role]
[security-role]
[description][/description]
[role-name]authenticated_user[/role-name]
[/security-role]

The above login-config enabled the application to use a WebSphere extension called Form-based authentication. WAS Form-based authentication will be introduced in a later post.

In WAS administrative console, in Applications - Enterprise Applications - [Appl] - Security role to user/group mapping, there were two lines

Role | Everyone? | All authenticated? | Mapped users | Mapped groups
authenticated_users | unchecked | checked | null | null
administrator | unchecked | unchecked | null | ceadmin

WAS was defined to use File-based J2EE security. See a previous post about File-based J2EE security for details.

In the groups.props, add a line ceadmin:101:tester:CE Administrative Group, where the 101 was the group number.

In the users.props, add a line tester:password:101:101:CE Admin Tester, where the first 101 was the user number and the second group number.

With the above definitions, the application was able to make use of WAS security and can distinguish users by their authentication and role.