8:28 a.m.
Thanks Anil,
Going over this again I think our default AS7 implementation of this is
wrong and the test cases in the testsuite are currently enforcing the
incorrect behaviour.
Taking the following jboss-web.xml example: -
<security-role>
<role-name>gooduser</role-name>
<principal-name>superuser</principal-name>
<principal-name>peter</principal-name>
</security-role>
If the users username is 'superuser' or 'peter' then it should be
assumed the user has the role 'gooduser'.
In the sun example they use an additional element <group-name> to map
from a group to a role - we do not support that concept.
For the AS8 / Undertow initial integration I am going to revert this
behaviour back to the original behaviour of assuming an additional role
if there is a match on the users principal and perform no matches on roles.
Short term anyone requiring a mapping of additional roles based on
current roles can use the existing login module provided for this
purpose - long term when we are talking about the PicketLink IDM
integration within AS we will need to review how we enable mapping
between identity store groups and the roles of individual applications.
Regards,
Darran Lofthouse.
On 15/03/13 18:34, Anil Saldhana wrote:
Darran,
<security-role> setting is present in jboss-web.xml, jboss-app.xml
and jboss.xml historically.
From the dtd definitions: http://www.jboss.org/j2ee/dtd/
<!--
The principal-name element is the name of the principal that is mapped
to the assembly role-name.
Used in: security-role
-->
Basically, the original intent was to map the assembly security role
(from security-role-ref from web.xml etc) to deployment
security-role/principal-name combination (vendor DD).
Something like:
http://docs.oracle.com/javaee/5/tutorial/doc/bncav.html#bncay
Regards,
Anil
On 03/14/2013 06:43 AM, Darran Lofthouse wrote:
> I am looking for some clarification regarding the <security-role>
> element in the jboss-web.xml - trying to dig through some historic use
> of the element I am starting to think a mistake was made in AS7 and that
> the mapping logic is not what was originally intended by the element.
>
> Take the following definition: -
>
> <security-role>
> <role-name>Support</role-name>
> <principal-name>Mark</principal-name>
> <principal-name>Tom</principal-name>
> </security-role>
>
> My interpretation of this is that originally this was used where we had
> a run-as-principal-define, this would mean if the run-as-principal is
> either 'Mark' or 'Tom' then assume that membership of the role
'Support'
> is also true.
>
> Where there is no run-as-principal I believe this also evolved to mean,
> if the authenticated user is 'Mark' or 'Tom' then assume that they
are a
> member of the role 'Support'.
>
> However for some reason within AS7 we seem to now be matching the
> principal-name values against the users currently assigned roles and not
> matching it against the name of the Principal.
>
> To me this new behaviour is wrong and is confusing but I wanted to check
> if there were other opinions. Where a role to role mapping is required
> there is already a login module to provide that capability and I think
> that has been confused with the principal to role mapping of the
> deployment descriptor.
>
> Regards,
> Darran Lofthouse.
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev