support any authenticated user role, **, in method permissions and in isCallerInRole

[glassfishrobot]

The following spec additions may be sufficient to support this new feature:

a. amend the description of the isCallerInRole (to say what it means to use ** with this method

b. amend the description of security roles, to introduce this new architected role, **, to say what it means, and to say something about how an application declared role with the same name would take precedence.

c. amend the description of p-2-role mapping, to say how this role must be mapped to every authenticated user.

d. and perhaps add something to the description of security-role-refs, to indicate if use of this role in isCallerInRole should be declared

Affected Versions

[3.2]

[glassfishrobot]

Reported by monzillo

[glassfishrobot]

kithouna said: Sorry if this is not the right place to ask this. But I noticed this same thing (the "all" role) has been requested for 3 places: Servlet spec, EJB spec and JACC spec.

If there was some underlying "handler" for role decisions, shouldn't this only have to be added in one spec, instead of 3?

Can JACC (or a simplified/improved version) become this underlying handler?

[glassfishrobot]

monzillo said: jacc probably woun't be the right place to do this; at least because its focus is on describing how the declarative security models of servlet and ejb can be conveyed to and enforced by an se policy subsystem.

The requirements in the servlet and ejb specs are both specific to their technology and somewhat decoupled from any specific implementation (of which using jacc would be one strategy).

Also servlet has a life outside of ee, which would likley mean that any such unification spec would need to be decoupled from ee.

It is also the case, that servlet and ejb have different security models, which would most likely need to be represented in any new spec.

so generally, I am in favor of reducing how many places the same stuff occurs, but I am pretty sure jacc (as it exists) would not be the right place to do that, and I also think the differences I alluded to above, would require separate treatment; which should likely remain in the individual specs, however (like the common annotations spec) perhaps there is an opportunity to factor some of this stuff out into a separate security spec, decribing the common aspects of the ee declarative security model.

[glassfishrobot]

mvatkina said: kithouna,

You can file a Feature request under the Java EE spec to move the common security requirements to a single document in EE 8.

[glassfishrobot]

mvatkina said: See http://java.net/projects/ejb-spec/downloads/download/security-chapter-changed.pdf

[glassfishrobot]

Was assigned to mvatkina

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-94

[glassfishrobot]

Marked as fixed on Thursday, March 7th 2013, 7:42:42 pm