Within Elytron custom PermissionMapper implementations can be provided either within the subsystem by providing the fully qualified class name of the implementation to use, or by depending on a capability exposed by another subsystem.  This article is to cover the default implementations that will be provided by Elytron and will be made available in the subsystem.

The API

Firstly this is a simplification of the API of the PermissionMapper: -

public interface PermissionMapper {
    PermissionVerifier mapPermissions(PermissionMappable permissionMappable, Roles roles);
}

https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/authz/PermissionMapper.java

In addition to the Roles additional information is available from the PermissionMappable: -

public interface PermissionMappable {
    Attributes getAttributes();

    Principal getPrincipal();

    Instant getCreationTime();
}

https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/authz/PermissionMappable.java

Finally here is a simplification of the PermissionVerifier: -

public interface PermissionVerifier {
    boolean implies(Permission permission);
}

wildfly-elytron/PermissionVerifier.java at master · wildfly-security/wildfly-elytron · GitHub

Logical Permission Mappers

The resulting PermissionVerifier instances can be combined logically using - and, or, xor, and unless.

Factory methods will be provided for PermissionMapper to take two or more PermissionMapper references - when called the resulting PermissionMapper will call each PermissionMapper in turn and then combine the resulting PermissionVerifier instances into one using the appropriate logical method.

Configured Permission Mapper

The intention is to provide a configurable PermissionMapper which provides a reasonable level of flexibility for administrators especially when combined with the logical permission mappers.

The intent however is not to cover every conceivable permission mapping use case, for the more advanced cases either custom implementations can be registered in the subsystem or even made available using capabilities and requirements.

PermissionVerifier from PermissionCollections

The permission mapper will map to permission verifiers created from a permission collection - no other variations of permision verifier construction will be considered.

The permission verifier will be defined as a set of permissions with optional names and actions.

The resulting permission verifier can also be negated.

Search Criteria

The permission verifiers created from a permission collection will be associated with a selection criteria which will contain: -

• A list of principal names.
• A list of role names.

If the PermissionMappable / SecurityIdentity matches a single principal name or single role name then the associated PermissionVerifier will be used.

Overall Configuration

The overall permission mapper configuration will be an ordered list of search criteria along with associated permission verifier definitions.

The permission mapper will also have a 'multiple-match' setting to define the behaviour if multiple search criteria match: -

• Use first match.
  • Only the first matching permission verifier will be used.
• and
  • All matching permission verifiers will be combined together using 'and'
• or
  • All matching permission verifiers will be combined together using 'or'
• xor
  • All matching permission verifiers will be combed together using 'xor'

If there is no match a permission verifier which rejects all permission checks is the default.