Skip navigation
2018

With WildFly 13, there’s a new way to configure permissions in the Elytron subsystem. In particular, it is now possible to configure permissions using a new permission-set resource.

 

Configuring permission sets

 

Adding a permission-set takes the following general form:

 

/subsystem=elytron/permission-set=MyPermissionSetName:add(permissions=[{class-name="...", module="...", target-name="...", action="..."}...])

 

In the above command, permissions consists of a set of permissions, where each permission can have the following attributes:

  • class-name - the fully qualified class name of the permission (this is the only permission attribute that is required)
  • module - the optional module to use to load the permission
  • target-name - the optional target name to pass to the permission as it is constructed
  • action - the optional action to pass to the permission as it is constructed

 

After a permission-set has been created, it can be referenced when creating a permission mapper in order to assign permissions to an identity.

 

Example configuration

 

As an example, the following command can be used to add a new permission-set that contains the org.wildfly.security.auth.permission.RunAsPrincipalPermission:

 

/subsystem=elytron/permission-set=run-as-principal-permission:add(permissions=[{class-name="org.wildfly.security.auth.permission.RunAsPrincipalPermission", target-name="*"}])

 

This results in the following configuration in the Elytron subsystem (note that the login-permission and default-permissions permission sets are already present in the default Elytron subsystem configuration):

 

<subsystem xmlns="urn:wildfly:elytron:3.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
...
    <permission-sets>
        <permission-set name="login-permission">
            <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
        </permission-set>
        <permission-set name="default-permissions">
            <permission class-name="org.wildfly.extension.batch.jberet.deployment.BatchPermission" module="org.wildfly.extension.batch.jberet" target-name="*"/>
            <permission class-name="org.wildfly.transaction.client.RemoteTransactionPermission" module="org.wildfly.transaction.client"/>
            <permission class-name="org.jboss.ejb.client.RemoteEJBPermission" module="org.jboss.ejb-client"/>
        </permission-set>
        <permission-set name="run-as-principal-permission">
            <permission class-name="org.wildfly.security.auth.permission.RunAsPrincipalPermission" target-name="*"/>
        </permission-set>
    </permission-sets>
...
</subsystem>

 

Next, create a simple permission mapper that references the newly created run-as-principal-permission permission set:

 

/subsystem=elytron/simple-permission-mapper=my-simple-permission-mapper:add(permission-mappings=[{principals=["anonymous"]}, \
{principals=["server1"], permission-sets=[{permission-set=login-permission}, {permission-set=default-permissions}, {permission-set=run-as-principal-permission}]}, \
{match-all=true,permission-sets=[{permission-set=login-permission}, {permission-set=default-permissions}]}])

 

This results in the following configuration in the Elytron subsystem:

 

<subsystem xmlns="urn:wildfly:elytron:3.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
...
    <mappers>
    ...
        <simple-permission-mapper name="my-simple-permission-mapper">
            <permission-mapping>
                <principal name="anonymous"/>
            </permission-mapping>
            <permission-mapping>
                <principal name="server1"/>
                <permission-set name="login-permission"/>
                <permission-set name="default-permissions"/>
                <permission-set name="run-as-principal-permission"/>
            </permission-mapping>
            <permission-mapping match-all="true">
                <permission-set name="login-permission"/>
                <permission-set name="default-permissions"/>
            </permission-mapping>
        </simple-permission-mapper>
    ...
    </mappers>
...
</subsystem>

 

The above command creates a simple permission mapper that:

  • Assigns no permissions to an anonymous user
  • Assigns the permissions referenced in the login-permission, default-permissions, and run-as-principal-permission permission sets to the server1 user
  • Assigns the permissions referenced in the login-permission and default-permissions permission sets to all other users

 

Summary

 

This blog post has given an overview of Elytron permission sets. For more information about the Elytron subsystem, check out the Elytron documentation.

Filter Blog

By date:
By tag: