You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2013/08/24 00:14:25 UTC
[Bug 55477] New: Add a solution to map an realm name to a security
role
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
Bug ID: 55477
Summary: Add a solution to map an realm name to a security role
Product: Tomcat 7
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: stefan@mayr-stefan.de
Created attachment 30759
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30759&action=edit
Prototype of a nestable realm
Sometimes it would be quite handy to translate role names of a configured realm
to the specifed security roles used in applications (web.xml). This would be
especially comfortable with the JNDIRealm.
Example:
#1 dev environment
map ldap group developers to security role manager-jmx
#2 production environment
map ldap group developers to security role manager-status
I've already created a prototype of a nestable realm using a simple properties
file (mapping.properties) for translation. I'm no programmer, so it might need
some cleanup.
Configuration could look like this (not tested with JNDI yet):
<Realm className="org.apache.catalina.realm.MappingRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #8 from Stefan Mayr <st...@mayr-stefan.de> ---
Christopers version would be like this:
<Realm class="...MappingRealm"
separator=",\s*"
assignment="->"
roleMappings="securityGroupName->innerRealmGroupName, otherName->3rdName"
....
/>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #6 from Stefan Mayr <st...@mayr-stefan.de> ---
I thought about defining a custom ressource to make an inline configuration
possible without messing with the Digester rules. So I searched and found
http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#Adding_Custom_Resource_Factories
If I understand this correct each attribute in the xml-Element resource will be
accessible by my resource object (com.mycompany.MyBean).
e.g.
>From the example:
<Resource name="bean/MyBeanFactory" auth="Container"
type="com.mycompany.MyBean"
factory="com.mycompany.MyBeanFactory"
bar="23"/>
here we can access to "bar" and its value "23". Some more google searches later
I found collection elements in spring beans:
http://static.springsource.org/spring/docs/1.2.9/reference/beans.html#beans-collection-elements
. There the bean attributes are configured using sub xml elements. But I cannot
find tomcat examples where some sort of collection is written as attribute
value (like bar="{collection-element-1}{collection-element-2}") in the
server.xml. I doubt this is even possible.
So I'm again with an external file, messing with strings or the digester rules.
Sorry if this is all a bit twisted. For me as a sysadmin programming is a not
so easy
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #5 from Christopher Schultz <ch...@christopherschultz.net> ---
I'm not sure I understand your statement. Can you explain further?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #7 from Stefan Mayr <st...@mayr-stefan.de> ---
Created attachment 30788
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30788&action=edit
Edition with inline configuration for the role mapping
I added the possibility to configure the mapping inline with the string
mangling solution
Example:
<Realm className="org.apache.catalina.realm.MappingRealm"
roleMappings="a=b;manager-gui=tomcat;c=d">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
Other attributes and their default values:
assignment="="
separator=";"
pathname="conf/mapping.properties"
People using JDNIRealms with LDAP DNs will have to change assignment and
separator (regex)strings. Maybe someone can come up with better default values.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #4 from Stefan Mayr <st...@mayr-stefan.de> ---
Usual bean settings (like for a custom resource) which can be expressed in sub
xml elements are attributes in the server.xml file.
configuration in beans:
<property name="map">
<props key="role1">value1</props>
<props key="role2">value2</props>
</property>
Tomcat: map="???"
Any pointer what I should search for?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
Yeah, you can access sub-elements (we use Digester, so it just needs to be
configured, but I'd prefer not to modify the digester configuration if it's not
necessary).
I was a little worried about the delimiter stuff, and no, there aren't any
rules against what a security role's name could be. I wanted to avoid commas
because obviously LDAP group names are littered with commas. The map would be a
nicer way to go. We could look to see if there's anything already recognized
under <Realm> that could be used, here, or if something new is more
appropriate.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
I haven't looked at the patch yet, but I wonder if configuring the
wrapper-realm could be done directly in the context.xml like this:
<Realm class="...MappingRealm"
map="realmGroupName->securityGroupName, otherName->3rdName">
...
</Realm>
Thoughts?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
Stefan Mayr <st...@mayr-stefan.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #30759|0 |1
is obsolete| |
Attachment #30788|0 |1
is obsolete| |
--- Comment #9 from Stefan Mayr <st...@mayr-stefan.de> ---
Created attachment 30805
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30805&action=edit
MappingRealm incl. docs
MappingRealm comments were reworked and initial documentation has been added to
docs/config/realm.xml and docs/realm-howto.xml (mostly copy & paste from
existing sections)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55477] Add a solution to map an realm name to a security role
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
--- Comment #2 from Stefan Mayr <st...@mayr-stefan.de> ---
Should be possible. Where to find the rules about the security role naming
conventions? The parsing of such an attribute might be tricky. Although this
could be controlled by extra parameters (delimiter,assignation) if the defaults
collide with names.
Is it possible to access XML-Elements under the defined Realm? I think of
something like
<Realm class="...MappingRealm">
<map security-role="r1" group-name="g1" />
<map security-role="r2" group-name="g2" />
...
</Realm>
An alternative could be using a ressource. Is it possible to use a map as
ressource?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org