1

I am not familiar with application server based security constraints. For the following web.xml example, I see the defined roles and which role can access the restricted resources.

<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Whatever</realm-name>
</login-config> 

<security-role>
    <description>Administrator Role</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Privileged User</description>
    <role-name>privileged</role-name>
</security-role>

<security-role>
    <description>Guest User</description>
    <role-name>guest</role-name>
</security-role>


<security-constraint>
    <web-resource-collection>
        <web-resource-name>Privileged area</web-resource-name>
        <url-pattern>/restricted/*</url-pattern>
    </web-resource-collection>
    
    <auth-constraint>
        <role-name>admin</role-name>
        <role-name>privileged</role-name>
    </auth-constraint> 
</security-constraint>

When the first time a user makes an http request to access a restricted page, they have no role and asked for user name/password. The container may validate the user name against a database and assign the user a role (e.g. admin). Where does the container store this role so that for subsequent http requests, it knows that the request has the appropriate role to access to the resource?

user2125853
  • 1,265
  • 4
  • 13
  • 23

1 Answers1

2

It is stored in the HTTP Session in the web container. Usually, the client will receive a session ID (usually in the form of a cookie, but it doesn't have to be) on its first request to the server - or the first request to the server after its previous session has expired. The client will then send that session ID on subsequent requests. Once the client is authenticated, its security context is stored in the HTTP Session associated with the session ID. The flow would look something like this:

Client: Hi, I'd like to access your service.

Server: Ok, who are you?

Client: I'm Bob, and this is my password. (sends credentials - doesn't have to be basic auth with username/password)

Server: Hi Bob - here's your ID card for your stay. It expires after 30 minutes of inactivity. Enjoy! (Sends session ID)

Client: Cool, I'd like to access resource XYZ. Here's my ID. (Sends session ID)

Server: No problem - we've checked the registry and determined that you are in a group that has permission to access XYZ. Enjoy!

Andy McCright
  • 1,273
  • 6
  • 8
  • Are there specific input fields the container is looking for in a login form? Also, if an application is providing its own login form and looking up the user role in a database table, does the application have to do something to store the role information in the session? Is there a specific attribute? – user2125853 Aug 26 '21 at 16:20
  • For form-based login, this page may be useful: https://www.ibm.com/support/pages/form-based-login-liberty - tl;dr your form should include text fields for `j_username` and `j_password` and the form itself should POST to `j_security_check`. If the application is doing the authentication check itself, then you'll probably need to implement a JAAS service - sorry, but I'm not an expert in that area. I generally just rely on the app server to handle the authentication. :) – Andy McCright Aug 26 '21 at 21:18
  • Let me look at the page. Thanks! – user2125853 Aug 26 '21 at 21:23