Wildcards in role-name

[adamcrume]

I work for a company with complex security needs. Rather than just
belonging to groups, users often have group membership based on
department. To accomplish this, we have group names that are
department ID + simple group name. For example, a user might be a
member of 01-viewlogs, 01-updatelogs, and 02-viewlogs. To be able to
check for group membership, I have to list every group in web.xml.
This is obviously a problem, because I'd have to have (number of
departments) * (number of simple groups) entries. In other words:
<security-role>
<role-name>01-viewlogs</role-name>
</security-role>
<security-role>
<role-name>02-viewlogs</role-name>
</security-role>
<security-role>
<role-name>01-updatelogs</role-name>
</security-role>
<security-role>
<role-name>02-updatelogs</role-name>
</security-role>
....

Is there any way around this, perhaps by using wildcards? As far as I
can tell, the spec only allows listing exact group names.

 

[Mark Space]

I work for a company with complex security needs. Rather than just
belonging to groups, users often have group membership based on
department. To accomplish this, we have group names that are
department ID + simple group name. For example, a user might be a
member of 01-viewlogs, 01-updatelogs, and 02-viewlogs. To be able to
check for group membership, I have to list every group in web.xml.
This is obviously a problem, because I'd have to have (number of
departments) * (number of simple groups) entries. In other words:

Why not just:

<departments>
<id>01</id>
<id>02</id>
...
</departments>
<roles>
<role>viewlogs</role>
<role>updatelogs</role>
...
</roles>

Then mung the IDs * names yourself? If you really need /all/ and all is
always ID * roles, it seems the best way.

You might want to look at not using these munged strings internally,
however, even if the external spec requires it. Munged strings are
almost always a rotten design pattern

<employ>
<name>Bob Joe</name>
<department-id>02</department-id>
<security-roles>
<role>viewlogs</role>
<role>rotatelogs</role>
</security-roles>
...

Makes it much easier to add departments or add roles. Or worse: remove
a department id. Ouch, I don't want to think about that with the string
version.

 

[Owen Jacobson]

Why not just:

<departments>
  <id>01</id>
  <id>02</id>
  ...
</departments>
<roles>
  <role>viewlogs</role>
  <role>updatelogs</role>
  ...
</roles>

Then mung the IDs * names yourself?  If you really need /all/ and all is
always ID * roles, it seems the best way.

You might want to look at not using these munged strings internally,
however, even if the external spec requires it.  Munged strings are
almost always a rotten design pattern

<employ>
   <name>Bob Joe</name>
   <department-id>02</department-id>
   <security-roles>
     <role>viewlogs</role>
     <role>rotatelogs</role>
   </security-roles>
   ...

Makes it much easier to add departments or add roles.  Or worse: remove
a department id.  Ouch, I don't want to think about that with the string
version.

This is one of those situations where an omitted fact makes a massive
difference in interpretation. From what I gather the OP is talking
about security-roles in the context of a webapp's web.xml descriptor,
which have a strictly fixed format.

To answer the OP's question, no, there is no standard support for
wildcards or patterns in role names. The intent is that you define
logical, app-specific roles in the portable descriptor and define how
they map to real users and roles using deployment-specific tools.
Personally, I think this is another fine example of how Java EE is
wildly disconnected from useful reality, but the concept itself isn't
bad. In your case, you'd have something like

<security-role>
<role-name>viewlogs</role-name>
</security-role>
<security-role>
<role-name>updatelogs</role-name>
</security-role>
<security-role>
<role-name>rotatelogs</role-name>
</security-role>

in web.xml, which describe the logical roles your app cares about. In
a server-specific bit of config you'd indicate which combinations of
department and role map to which logical roles. Depending on your app
server and on your willingness to write some glue code this could be
easy or hard to accomplish.

-o

 

[adamcrume]

This is one of those situations where an omitted fact makes a massive
difference in interpretation.  From what I gather the OP is talking
about security-roles in the context of a webapp's web.xml descriptor,
which have a strictly fixed format.

To answer the OP's question, no, there is no standard support for
wildcards or patterns in role names.  The intent is that you define
logical, app-specific roles in the portable descriptor and define how
they map to real users and roles using deployment-specific tools.
Personally, I think this is another fine example of how Java EE is
wildly disconnected from useful reality, but the concept itself isn't
bad.  In your case, you'd have something like

<security-role>
  <role-name>viewlogs</role-name>
</security-role>
<security-role>
  <role-name>updatelogs</role-name>
</security-role>
<security-role>
  <role-name>rotatelogs</role-name>
</security-role>

in web.xml, which describe the logical roles your app cares about.  In
a server-specific bit of config you'd indicate which combinations of
department and role map to which logical roles.  Depending on your app
server and on your willingness to write some glue code this could be
easy or hard to accomplish.

-o

I'm sorry; you're correct. I am talking about a J2EE web app. My
problem is still that, unless I bypass J2EE roles entirely, I have to
list every one in web.xml. It's bad enough that this would be a huge
number. The worst part is that we add departments regularly, and when
that happens, we'd have to add a role for every simple group and
redeploy every web app.

I guess the bottom line is that I either have to find some completely
different way of handling things, bypass J2EE security, or just deal
with this huge headache. The last two options are quite unpleasant,
and I'm fresh out of ideas on the first one. If anyone has any crazy,
out-of-left-field ideas, I'd be happy to hear them.