J2EE Container Security - Duplication inevitable? (Attn: Frank)

Question

Frank:
Just to be clear, so you are saying I will have duplication of roles in "application_roles" table and the web.xml. And, this is the only way I could "authenticate" using "application_users" table data and "authorize" using "application_roles" existing in a totally different database schema!
Hmmm. Almost seems like existence of "application_roles" table is not required in the setup I described. After authentication, I have to hit the web.xml to get the roles for the authenticated users anyway? Why bother with extra work with database? Am I right?
By the way, I am repeating my setup and your answers to refresh your memory because you get many inquiries.
UPDATE as of 14:30 pm. I think I may be showing my ignorance here. I guess user's role is decided by table "application_roles." You then use the isUserInRole() merely to set read/write/view permissions. But, I am not quite sure yet. Hence I will leave this post for your answer. I am not quite done with my analysis before deciding to change this post.
Thanks
To refresh:
My set up. I have ADFBC. I have using SRDemo with a twist. I am using your new doc "Database authentication and Auth in J2EE container managed security."- not ADF security from SRDemo's last chapter. I ignored the ADF Security part in the SRDemo. I have "application_roles" and srdemo tables in one database schema and "application_users" in a totally different schema.
You wrote:
web.xml is used to define authorization based on security constraints expressed in URL patterns. However, for each of the user roles - e.g. PRESIDENT - you need to create a role in web.xml with the same name. When you then call isUserInRole() from the JSF application then it checks web.xml for the security role and then attempts to verify that the user has this role granted. It is not obvious why web.xml needs to have the role defined. There exists a reason that however would add more to your confusion than to your success ;-)
Youcan use the same approach SRDemo uses in that you provide a managed bean with boolean methods like isPresident(), isManager() etc. The methods perform "isUserInRole()"
Then you use EL to access these methods to hide/show components

Answer 1

Hi
Just to be clear, so you are saying I will have duplication of roles in "application_roles" table and the web.xml. And, this is the only way I could "authenticate" using "application_users" table data and "authorize" using "application_roles" existing in a totally different database schema!
The table is the security provider wheras web.xml defines the security roles that you can work with in your program code. The J2EE servlet spec defines a separation of application roles and groups or roles in the security provider. There is an additional step between roles in web.xml and the security provider, which is that you could map the role name in web.xml to a security role name. I never tested this with custom LoginModules and for this reason the two role names match.
The goal of container managed security is that the developer can build the secure web application without having to know about the security roles defined on the security provider.
Note that anything that you call in application code within container managed security - and this is not specific to Oracle - is checked against the web.xml file which is mapped to the security provider. If e.g. you use JBoss then you could configure a database module to handle the authentication and authorization. But still the security role needs to be provided in web.xml
Frank