Topics

Default group to role mapping


Will Hopkins
 

I've gotten some feedback on the default group -> role mapping that I'd like to share with the EG:
  • The first is some concern about the impact of a default mapping on security. It's been pointed out that a default mapping will have the effect of automatically granting privileges to users who happen to be members of groups named for roles of an application that's deployed. That won't be a big deal for an application with a dedicated user store, but in enterprise deployments the user store is often a pre-existing store populated with all of the enterprise's users. In that kind of environment anybody who is a member of "user" or "admin" or "manager" groups, etc., might automatically -- and unexpectedly -- get privileges for a newly deployed app that used those names for roles,
  • Separately, someone from the Glassfish team pointed out that GF already has this functionality, but that it's off by default. Turning it on by default could break compatibility, or create security holes, if an existing environment was upgraded to the latest GF.
I'd like to propose changing the requirement slightly, to say that a conformant implementation MUST provide a mode in which there is automatic group -> role mapping, but that the mode is NOT REQUIRED to be enabled by default.

Thoughts?

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Rudy De Busscher
 

Hi Will,

I can following the reasoning, but the remarks feel a bit awkward. Human error always has a consequence, also when you have some kind of mapping which isn't  a default one. 
When you add the user to a group called 'foo' but that group is mapped to the role 'admin' for some application, it is even harder to find out what the user exactly can do within each application.

Roles are too broad and impractical anyway. That is the reason why I don't like any role based system for your application (and never use by the way). You need a permission-based system, like RBAC which despite the name has little to do with roles.

But I can agree with the wording that it is not done by default, but there should be an option to do so.

Any proposal where the option will be defined, a new section within web.xml?

best regards
Rudy


On 29 June 2017 at 17:43, Will Hopkins <will.hopkins@...> wrote:
I've gotten some feedback on the default group -> role mapping that I'd like to share with the EG:
  • The first is some concern about the impact of a default mapping on security. It's been pointed out that a default mapping will have the effect of automatically granting privileges to users who happen to be members of groups named for roles of an application that's deployed. That won't be a big deal for an application with a dedicated user store, but in enterprise deployments the user store is often a pre-existing store populated with all of the enterprise's users. In that kind of environment anybody who is a member of "user" or "admin" or "manager" groups, etc., might automatically -- and unexpectedly -- get privileges for a newly deployed app that used those names for roles,
  • Separately, someone from the Glassfish team pointed out that GF already has this functionality, but that it's off by default. Turning it on by default could break compatibility, or create security holes, if an existing environment was upgraded to the latest GF.
I'd like to propose changing the requirement slightly, to say that a conformant implementation MUST provide a mode in which there is automatic group -> role mapping, but that the mode is NOT REQUIRED to be enabled by default.

Thoughts?

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Arjan Tijms
 

Hi,

On Thursday, June 29, 2017, Will Hopkins <will.hopkins@...> wrote:
I've gotten some feedback on the default group -> role mapping that I'd like to share with the EG:
  • The first is some concern about the impact of a default mapping on security. It's been pointed out that a default mapping will have the effect of automatically granting privileges to users who happen to be members of groups named for roles of an application that's deployed. That won't be a big deal for an application with a dedicated user store, but in enterprise deployments the user store is often a pre-existing store populated with all of the enterprise's users. In that kind of environment anybody who is a member of "user" or "admin" or "manager" groups, etc., might automatically -- and unexpectedly -- get privileges for a newly deployed app that used those names for roles,
WebLogic currently already has default group to role mapping if no other explicit mapping (such as in weblogic-web.xml) has been done, so that should not be a concern there (it already happens).

Same holds for WebSphere Liberty; if JASPIC is used it does default group to role mapping.

JBoss WildFly has always done default group to role mapping.

For Payara Micro we switched to default group to role mapping as well.

TomEE does default mapping too.

GlassFish indeed has the option for it, but defaults to false.

Since WebLogic did the switch as well as did Payara Micro, I think GlassFish should be able to switch too. As the RI I'm not sure it really needs to be ultra conservative here (you would expect that from WebLogic and WebSphere Liberty, but even they made the switch).

That all said, the ultra conservative option is to default to default group to role mapping when JSR 375 is used. I'm fairly sure this is not really needed, as again several other servers already switched, plus it is only supposed to default to this if no explicit mapping is present.

  • Separately, someone from the Glassfish team pointed out that GF already has this functionality, but that it's off by default. Turning it on by default could break compatibility, or create security holes, if an existing environment was upgraded to the latest GF.
I'd like to propose changing the requirement slightly, to say that a conformant implementation MUST provide a mode in which there is automatic group -> role mapping, but that the mode is NOT REQUIRED to be enabled by default.

Thoughts?

Must provide is not sufficient as it clashes with the main goal that JSR 375 must be usuable without any server specific configuration needed. I.e. it MUST work out of the box.

If we state the requirement as above there's a real risk that GlassFish keeps the switch at false and keeps requiring developers to change this in the admin console (which goes against everything JSR 375 stands for).

There are only 3 real possibilities that I can think of really (in order of preference).

In the absence of server specific configuration:

1. default to group to role mapping when JASPIC is used
2. default to group to role mapping when JSR 375 is used
3. provide a *portable* switch to enable default group to role mapping (e.g. SecurityContext.setGroupToRoleMapping(default) and/or a tag in web.xm)

Note the "in the absence of" main constraint. That will mean the overwhelming number of environments are not affected at all.

Kind regards,
Arjan



 


Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

 


reza_rahman <reza_rahman@...>
 

I agree with Arjan. In a vast majority of cases, default mapping is just fine. Indeed I have not seen it the other way around in a very long time.

-------- Original message --------
From: Arjan Tijms <arjan.tijms@...>
Date: 6/29/17 4:01 PM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: Re: [javaee-security-spec] Default group to role mapping

Hi,

On Thursday, June 29, 2017, Will Hopkins <will.hopkins@...> wrote:
I've gotten some feedback on the default group -> role mapping that I'd like to share with the EG:
  • The first is some concern about the impact of a default mapping on security. It's been pointed out that a default mapping will have the effect of automatically granting privileges to users who happen to be members of groups named for roles of an application that's deployed. That won't be a big deal for an application with a dedicated user store, but in enterprise deployments the user store is often a pre-existing store populated with all of the enterprise's users. In that kind of environment anybody who is a member of "user" or "admin" or "manager" groups, etc., might automatically -- and unexpectedly -- get privileges for a newly deployed app that used those names for roles,
WebLogic currently already has default group to role mapping if no other explicit mapping (such as in weblogic-web.xml) has been done, so that should not be a concern there (it already happens).

Same holds for WebSphere Liberty; if JASPIC is used it does default group to role mapping.

JBoss WildFly has always done default group to role mapping.

For Payara Micro we switched to default group to role mapping as well.

TomEE does default mapping too.

GlassFish indeed has the option for it, but defaults to false.

Since WebLogic did the switch as well as did Payara Micro, I think GlassFish should be able to switch too. As the RI I'm not sure it really needs to be ultra conservative here (you would expect that from WebLogic and WebSphere Liberty, but even they made the switch).

That all said, the ultra conservative option is to default to default group to role mapping when JSR 375 is used. I'm fairly sure this is not really needed, as again several other servers already switched, plus it is only supposed to default to this if no explicit mapping is present.

  • Separately, someone from the Glassfish team pointed out that GF already has this functionality, but that it's off by default. Turning it on by default could break compatibility, or create security holes, if an existing environment was upgraded to the latest GF.
I'd like to propose changing the requirement slightly, to say that a conformant implementation MUST provide a mode in which there is automatic group -> role mapping, but that the mode is NOT REQUIRED to be enabled by default.

Thoughts?

Must provide is not sufficient as it clashes with the main goal that JSR 375 must be usuable without any server specific configuration needed. I.e. it MUST work out of the box.

If we state the requirement as above there's a real risk that GlassFish keeps the switch at false and keeps requiring developers to change this in the admin console (which goes against everything JSR 375 stands for).

There are only 3 real possibilities that I can think of really (in order of preference).

In the absence of server specific configuration:

1. default to group to role mapping when JASPIC is used
2. default to group to role mapping when JSR 375 is used
3. provide a *portable* switch to enable default group to role mapping (e.g. SecurityContext.setGroupToRoleMapping(default) and/or a tag in web.xm)

Note the "in the absence of" main constraint. That will mean the overwhelming number of environments are not affected at all.

Kind regards,
Arjan



 


Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

 


Guillermo González de Agüero
 

Hi,

I'm with everybody else in that the mapping should be enabled by default. At least when JSR 375 is in use. For consistency reasons people will expect it to work on the "legacy" mechanism, but I doubt much people will use it once this spec is available.

But, given what Arjan said, I don't think changing it would be a big deal, as this is the default behavior in every server but on GlassFish. Removing this manual mapping requirement would remove the need for another vendor-specific configuration.


Regards,

Guillermo González de Agüero

On Thu, Jun 29, 2017 at 5:43 PM, Will Hopkins <will.hopkins@...> wrote:
I've gotten some feedback on the default group -> role mapping that I'd like to share with the EG:
  • The first is some concern about the impact of a default mapping on security. It's been pointed out that a default mapping will have the effect of automatically granting privileges to users who happen to be members of groups named for roles of an application that's deployed. That won't be a big deal for an application with a dedicated user store, but in enterprise deployments the user store is often a pre-existing store populated with all of the enterprise's users. In that kind of environment anybody who is a member of "user" or "admin" or "manager" groups, etc., might automatically -- and unexpectedly -- get privileges for a newly deployed app that used those names for roles,
  • Separately, someone from the Glassfish team pointed out that GF already has this functionality, but that it's off by default. Turning it on by default could break compatibility, or create security holes, if an existing environment was upgraded to the latest GF.
I'd like to propose changing the requirement slightly, to say that a conformant implementation MUST provide a mode in which there is automatic group -> role mapping, but that the mode is NOT REQUIRED to be enabled by default.

Thoughts?

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Rudy De Busscher
 

Hi,

In any case, for me, the group to role mapping must be configurable in a standardized way. So it is no option that it will be handled by a server application specific config.

If it is really an issue for Glassfish then we could make the value to false (when not specified) so that at least 99% of the other user can specify the value true.
But since the majority of the servers do already default mapping, I prefer to have it also by default enabled.

Regards
Rudy


Will Hopkins
 

Let's leave the current spec language as it is, then.

On 06/30/2017 02:42 PM, Rudy De Busscher wrote:
Hi,

In any case, for me, the group to role mapping must be configurable in a standardized way. So it is no option that it will be handled by a server application specific config.

If it is really an issue for Glassfish then we could make the value to false (when not specified) so that at least 99% of the other user can specify the value true.
But since the majority of the servers do already default mapping, I prefer to have it also by default enabled.

Regards
Rudy

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


David Blevins
 

I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)


Will Hopkins
 

Good to know, on both counts. :)

The consensus was to keep the mapping enabled by default, so that's what the spec still says.

Thanks,

Will


On 07/10/2017 08:42 PM, dblevins@... wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Darran Lofthouse
 

I am probably missing this, where are we supposed to be casing this vote?


On Tue, 11 Jul 2017 at 01:54 <dblevins@...> wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)


Arjan Tijms
 

It seems the ballot has already been accepted. Red Hat indeed didn't vote. See here: https://jcp.org/en/jsr/results?id=6011

On Tue, Jul 11, 2017 at 11:17 AM, Darran Lofthouse <darran.lofthouse@...> wrote:
I am probably missing this, where are we supposed to be casing this vote?

On Tue, 11 Jul 2017 at 01:54 <dblevins@...> wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)



Arjan Tijms
 

Hi,

On Mon, Jul 10, 2017 at 05:54 pm, David Blevins wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.
Great, still very good to have that choice validated by such a long time Java EE expert as yourself :)


Incidentally, we also cast a yes vote on the Public Review Ballot :)

Thanks! :)

Kind regards,
Arjan Tijms