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.
But the server needs a default roleMapper which is configured by the XML
configs.
Thx
Rudy
On 16 March 2015 at 17:20, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Mon, Mar 16, 2015 at 4:32 PM, Rudy De Busscher <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> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Mar 16, 2015 at 3:53 AM, David Blevins <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
>>>>
>>>>
>>>
>>
>