Are you referring to applications being able to change roles of users during runtime? Would a Java EE API allowing applications to create users and change roles assigned satisfy this?
Although that wasn't what I meant with the above, that functionality is most definitely needed as well. I created a separate issue some time ago for that: JASPIC_SPEC-22
That is, not requiring all roles declared upfront (via web.xml or @DeclareRoles) and conditioning the authorization on the result of a calculation using an arbitrary role name?
Yes, that's it
Would you please provide a use case for this?
There are actually two use cases for this.
The first is about convenience and simplifications. The problem here is that "registering things in XML" is a kind of universal pain that Java EE users have had to endure, and I'm convinced it's one of the things that gave Java EE a bad name. JSF users had to register components, converters, validators and what have you in XML before they could be used. Early EJB users had to do a similar thing. An ongoing effort to make Java EE simpler is to omit these registrations or make them optional, especially if they don't really serve a purpose from the point of view of the end-user.
Role registration in Java EE is just like that. Suppose a SAM sets the authenticated result to consist of a user "Pete" with roles "foo" and "bar". Then having to register "foo" and "bar" in some XML file is just a nuisance to the user. It's hard to explain to them why the registration is needed. Older explanations used to say in very formal language about the 'deployer' being able to 'obtain a security view of the application' and then be able to 'map it to the runtime environment'.
Many users I'm afraid would just stare at that for a moment, shrug, and then just don't use Java EE security.
If no role mapping is used, then there's no security view for a deployer needed for mapping the roles, hence declaration would not be needed. While at the topic of security view for a deployer. I haven't really seen this happening in practice. Deploys are mostly automated via something like Jenkins these days. There's no actual person that during deployment uses some tooling that gives a list back of all roles in the app, then at the spot goes on mapping names on this list to roles in the environment. While theoretically maybe useful in practice to deploy unknown externally obtained apps, I don't think this is how modern software development cycles work in practice.
So requiring roles to be declared makes what I think is a minor use case possible, while causing much pain for a larger amount of people.
The other use case concerns systems where pages are added dynamically and external users register with the system (e.g. a typical public Wordpress or Wiki scenario). In such systems it might be wanted to create roles dynamically at run-time and then access them to users dynamically at run-time (note that it's not required for this mechanism to let users get those roles while logged-in; a log-out/log-in would be okay here). Examples of such roles might be "ACCESS_COMPUTERS_PAGE" or "EDIT_COMPUTERS_PAGE", etc.
Of course there are plenty of other mechanisms to realize the above, but I've seen people who wanted to do stuff like that.
There's one big complication to the dynamic role mapping, and that complication is called JACC.
From my article on this:
Typically JACC providers will create the total list of WebRoleRefPermission instances when an application is deployed and then return a sub-selection based on the Principals that we (indirectly) passed in our call to Policy#getPermissions. This however requires that all roles are statically and upfront declared. But a JASPIC auth module can dynamically return any amount of roles to the container and via HttpServletRequest#isUserInRole() an application can dynamically query for any such role without anything needing to be declared. Unfortunately such dynamic role usage typically doesn't work when JACC is used (the Java EE specification also forbids this, but on servers like JBoss it works anyway).
The most important purpose of this issue remains the standardized role mapping itself (which incidentally can also be used then to plug a major hole in JACC) with the special case of no role mapping.
Not having to declare roles is a nice bonus that makes things a lot easier to many users, but may things difficult for JACC. While I think JACC isn't used that much by users, servers like GlassFish use it internally.