Hi, i was quick reading the security part of the serlvet specification (1.3) to get more knowledge about container managed security. I got confused in some aspects and would appreciate any help.
I'm gonna ask a few questions, but if you answer one of them you might be also answering the next one, so if it happens, please just point the fact. I'm using JBoss 3.2.3/Tomcat 4.1
Question 1 - I got this from the serlvet spec: "If no security-role-ref element matching a security-role element has been declared, the container must default to checking the role-name element argument against the list of security-role elements for the web application. The isUserInRole method references the list to determine whether the caller is mapped to a security role."
Problem: I got a user which his login is John, and he also belons to the role JohnRole (in my Roles database table). The only security-role element i got in my web.xml is the following:
As you can see, there's no "JohnRole" in my web.xml, but as i said, John belongs to role JohnRole in my database table. Then, i log in my app as "John" and try to use the method request.isUserInRole("JohnRole") which returns TRUE. It makes sense, of course, because John actually belongs to the role JohnRole.
Well, if i'm not wrong, i think that Tomcat just contradicted the servlet spec. that says "The isUserInRole method references the list to determine whether the caller is mapped to a security role." As i just said, the role-name "JohnRole" is not on my web.xml list.
Question 2 - I don't get the point of those security-role tags elements. As i just said, a search in database to verity if the user belong to such a role will be made anyway. For what should we use this security-role element for???
Question 3 - Having all the above in mind, i thought that the security-role tag element could be used to propagation os security stuff to the ejb layer, but quickly i gave up this option, as the ejb deployment descpriptor alreayd have this method permission roles declarations.
Thanks if you help me better understand it. [ August 23, 2004: Message edited by: Leandro Melo ]
Since no one else has answered, I'll take a stab.... I'm no expert on this (hopefully the experts will correct me if I am wrong)
The security-role and security-role-ref elements are not used to define the roles and users, that is done by putting values in a database (in your case). The security-role element is just used to define which roles are referenced within the deployment descriptor. The security-role-ref then allows you to map these external roles to internal names.
So, if you have an application that has existing roles of "admin" and "user", and you wanted to have internal names of "SuperUser" and "NormalUser" (not a bad idea), you could add this:
So, if someone happened to belong to the role of "admin", you can check for isUserInRole("SuperUser") or isUserInRole("admin"). By using SuperUser, you allow flexibility in case the name of the admin role changes to administrator. In that case you would only need to change your deployment descriptor, not the source.
The line you were quoting basically says that if there is no security-role-ref with the role-name supplied to isUserInRole, then the system must only look at the defined security roles.
Joined: Mar 27, 2004
Thanks Brian, your comments make sense and are probably correct.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com