Re: Wildcards in role-name
On Aug 27, 3:19 pm, Mark Space <marksp...@sbcglobal.net> wrote:
adamcr...@gmail.com wrote:
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 i=
s
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 strin=
g
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