Hi,
On Monday, March 16, 2015, Rudy De Busscher <rdebusscher_at_gmail.com> wrote:
> Ok, much clearer now.
>
> Since the 'system' already uses this kind of mapping today (Java EE 7 and
> previous ones), it wasn't clear for me why you should need this
> additionally in your own code.
> But if we define it explicitly, it is easier to intervene if you
> want/need/what ever reason you have to fiddle with the mapping role <->
> group.
>
Indeed, for regular application code this should be relatively rare. For
authorization code this is a question of something that may not be needed
that often either, but if you need it, you really really need it.
This kind of gaping hole in the EE security specs was identified a long
time ago. I found references to plans of this needed to be standardised in
documents from the J2EE 1.4 era.
> But the server needs a default roleMapper which is configured by the XML
> configs.
>
Yes, that too. There may be a small challenge how to best specify this.
The role mapper should provide access to the role mapping that is done in a
server specific way, but it should also be possible to provide a role
mapping using standard syntax (e.g web.xml, and perhaps additionally via
annotations and/or programmatic).
The question then is what to do if both are specified? Merge mappings?
Proprietary overrides standard mapping? Allow the application to set a
merge mode (e.g "none", "mix", etc)?
Kind regards,
Arjan Tijms
>
>
> Thx
> Rudy
>
> On 16 March 2015 at 17:20, arjan tijms <arjan.tijms_at_gmail.com
> <javascript:_e(%7B%7D,'cvml','arjan.tijms_at_gmail.com');>> wrote:
>
>> Hi,
>>
>> On Mon, Mar 16, 2015 at 4:32 PM, Rudy De Busscher <rdebusscher_at_gmail.com
>> <javascript:_e(%7B%7D,'cvml','rdebusscher_at_gmail.com');>> wrote:
>>
>>> I can see that it is important that you have the possibility to define
>>> some kind of mapping for your application between roles and groups.
>>>
>>> But I don't immediately see a use-case why you should retrieve them in
>>> code.
>>>
>>
>> The main use case is for authorization modules, which need to check
>> application defined roles against the groups which are stored inside the
>> authenticated subject.
>>
>> The root issue is that role mapping exists, and that it's clearly useful,
>> so we can't just leave it out (nobody is arguing about that of course).
>> Then subsequently, authentication modules (proprietary or JASPIC based)
>> store groups inside the authenticated Subject, not roles. The
>> authentication code is never doing that mapping.
>>
>> When we have an authorization module, e.g. one that checks the
>> @RolesAllowed condition, it gets a role as input. Using the example above
>> that could be "appArchitect". This authorization module then checks the
>> Subject, and (assuming it knows the format, since this is container
>> specific) it finds the group "systemArchitect" there.
>>
>> Now by using standard APIs, the authorization module does not know
>> whether:
>>
>> 1. There has been any role mapping used at all
>> 2. If role mapping was used, whether the requested role "appArchitect"
>> maps to "systemArchitect" or not.
>>
>> See e.g. the comments beneath the article here:
>> http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html
>>
>> Without access to the role mapper (and therefor assuming no mapping) the
>> authorization module simply doesn't work for a lot of cases.
>>
>> Hope it's more clear now ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>>
>>> Thx
>>> Rudy
>>>
>>> On 16 March 2015 at 15:50, arjan tijms <arjan.tijms_at_gmail.com
>>> <javascript:_e(%7B%7D,'cvml','arjan.tijms_at_gmail.com');>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Mar 16, 2015 at 3:53 AM, David Blevins <dblevins_at_tomitribe.com
>>>> <javascript:_e(%7B%7D,'cvml','dblevins_at_tomitribe.com');>> wrote:
>>>>
>>>>> Would love to see even some spitballing on what the Role Service
>>>>> mentioned in the 375 proposal might look like.
>>>>>
>>>>
>>>> I wondered about that too really.
>>>>
>>>> There are essentially two interpretations in my mind;
>>>>
>>>> 1. It's the part of the "authentication store" (for which we still
>>>> don't have a name, hence it makes almost every discussion like this too
>>>> more difficult), that retrieves the roles of the current user whenever that
>>>> user logs in.
>>>>
>>>> 2. It provides applications access to the role mapping such as asked
>>>> for in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-8
>>>>
>>>> I think having a separate entity to retrieve the roles of the current
>>>> user is not that convenient. I'd rather see 1 entity for that such as
>>>> intended by https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-1,
>>>> https://java.net/jira/browse/JAVAEE_SPEC-25 and
>>>> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-9
>>>>
>>>> To clarify the second interpretation, suppose we'd have a (vendor
>>>> specific) configuration file like glassfish-web.xml containing the
>>>> following:
>>>>
>>>> <glassfish-web-app>
>>>>
>>>> <security-role-mapping>
>>>> <role-name>appArchitect</role-name>
>>>> <group-name>systemArchitect</group-name>
>>>> </security-role-mapping>
>>>>
>>>> </glassfish-web-app>
>>>>
>>>> Then the role service would allow me to query that the group
>>>> "systemArchitect" maps to the role "appArchitect" and the other way around.
>>>>
>>>> I'd prefer to use the term role mapper for this though instead of role
>>>> service.
>>>>
>>>> I recently published two articles that discuss role mapping, and which
>>>> are hopefully helpful here.
>>>>
>>>> See
>>>>
>>>> *
>>>> http://arjan-tijms.omnifaces.org/2014/12/java-ee-authorization-jacc-revisited.html
>>>> (general role mapping concepts)
>>>> *
>>>> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>>>> (native role mappers of GlassFish, WebLogic and Geronimo)
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Sometimes the bad idea is better than the good one -- we can all see
>>>>> what a bad version might look like and get our brains in gear.
>>>>>
>>>>>
>>>>> --
>>>>> David Blevins
>>>>> http://twitter.com/dblevins
>>>>> http://www.tomitribe.com
>>>>> 310-633-3852
>>>>>
>>>>>
>>>>
>>>
>>
>