No way to get all declared roles from SecurityContext

[vanuatoo]

Presently there is no way to get Set of groups that were set during credential validation.
Soteria has this method but it's not present in API

https://github.com/javaee/security-soteria/blob/master/impl/src/main/java/org/glassfish/soteria/SecurityContextImpl.java

Because of that redundant database lookup is required during login process.

[arjantijms]

I had initially added this to the SecurityContext, but it indeed never made it into the API. For the coming version it might be a good idea to add it indeed.

Note that there's generally a couple of ways to go about this. In the presence of a custom authorization module, the roles may be dynamic and there may be no support to get them all (or they may be near infinite). That's why in Soteria they are called declared roles.

See also https://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html#all-roles

The other option would be to have functionality (typically called a role mapper) that is capable to read roles from the current Subject. We essentially need that one anyway to strengthen Jakarta Authorization.

[vanuatoo]

I have 2 scenarios:

1. roles are stored in the database. session id is received from the client via cookie.
2. roles are part of JWT token which is received from the client via header

In both cases roles are finite and like Soteria does there should be a way to access them as a Set

[darranl]

The way we have handled this within our own APIs and SPIs within WildFly is to make sure our roles representation is Iterable, this way the SPI is not forcing implementations to load all at once when it may not be appropriate to proactively load all at once.

[arjantijms]

We could make the API return an Iterable, just to be sure.

Though if the API is about guaranteeing only "declared" roles (roles appearing in @DeclareRoles, other annotations or things like web.xml), the chance of this being huge by surprise seems manageable.

[darranl]

Yeah if this is about a finite set based on the configuration and the annotations maybe being iterable is not needed.

[arjantijms]

We should put a clarification in the javadoc that it only returns roles that have in some way been declared (giving the examples above), and not roles that have been dynamically added in some way.

Underlying things like PermissionCollection aren't expected to be infinite either, so the underlying Policy (or its replacement, as Policy itself will be removed) already has to make sure not to return something infinite there.

The question is whether we also need a method supporting dynamic roles, which should then return in Iterable?