Version 4

    This document is to describe the scenarios to be covered by WFLY-455 and as those scenarios are implemented will be updated to show the example configuration for each scenario.



    The authentication process and group loading occur as two distinct steps: -

    1. Validate the response recieved from the client in response to a challenge previously sent to the client.
    2. Based on the users confirmed identity perform the required searches to load the users groups.


    WFLY-455 is the implementation of step 2 to load the users group information from LDAP, this could occur after step 1 has validated the user against LDAP or a completely different approach.


    Where steps 1 and 2 both involve LDAP queries against the same server the connection should be cached to avoid the overhead of establishing a connection twice.  Connection pooling may also be applicable.


    Where step 1 is against LDAP and some generic query is performed based on the users identity this should be available to step 2 for re-use.  A common example would be converting from the users supplied username to their distinguished name, if this conversion has already occurred in step 1 it should not be repeated in step 2.


    In step 1 multiple backing stores could have been defined, e.g. a trust store as well as a ldap definition or in the future a SPNEGO definition and a LDAP definition.  Need to consider scenarios where one LDAP definition to load groups does not make sense, e.g. where a client certificate was used for authentication we may want to load the roles from a properties file but if SPNEGO or LDAP based PLAIN authentication was used load the groups from LDAP.



    There are two levels of recursion to be considered when searching for groups: -

    1. Groups at different levels in the LDAP hierarchy, the search will need to be configured to search below the root distinguished name.
    2. As each group is loaded the group could also be a member of additional groups so the search process would recursively look for additional groups.


    Additional Group Queries

    Some LDAP installation allow for a user to be assigned one additional group on top of any groups identified by executing the group loading searches - an example of this is Microsoft Active Directory where a user is assigned a primary group that is referenced using an internal identifier that then needs to be cross referenced with the actual groups to identify the corresponding groups.


    Group Mapping

    An additional option to consider is allowing an override of the groups actually loaded from LDAP, this would really be a third step in the authentication process so it not being considered at the moment.  Where groups are assigned to roles for the purpose of access control the configuration should be flexible enough to cope with multiple groups being mapped to the same role.


    LDIF Examples


    Example 1 - Active Directory

    The following LDIF extract demonstrates a standard Active Directory installation where various directions of group memberships are shown across different locations within the hierarchy and through the primary group association.


    dn: CN=Darran A. Lofthouse,CN=Users,DC=darranl,DC=jboss,DC=org
    memberOf: CN=Support Admin,OU=support,DC=darranl,DC=jboss,DC=org
    memberOf: CN=Investment Banker,CN=Users,DC=darranl,DC=jboss,DC=org
    memberOf: CN=Users,CN=Builtin,DC=darranl,DC=jboss,DC=org
    primaryGroupID: 513
    objectSid:: AQUAAAAAAAUVAAAAotmuNBRw7meCijOMTwQAAA==
    sAMAccountName: darranl
    dn: CN=Domain Users,CN=Users,DC=darranl,DC=jboss,DC=org
    objectClass: group
    cn: Domain Users
    memberOf: CN=Users,CN=Builtin,DC=darranl,DC=jboss,DC=org
    memberOf: CN=Support User,OU=support,DC=darranl,DC=jboss,DC=org
    name: Domain Users
    objectGUID:: Mwv5vtu82E+FvTtbhUSmzA==
    sAMAccountName: Domain Users
    dn: CN=Users,CN=Builtin,DC=darranl,DC=jboss,DC=org
    objectClass: group
    cn: Users
    member: CN=Darran A. Lofthouse,CN=Users,DC=darranl,DC=jboss,DC=org
    member: CN=Domain Users,CN=Users,DC=darranl,DC=jboss,DC=org
    distinguishedName: CN=Users,CN=Builtin,DC=darranl,DC=jboss,DC=org
    name: Users
    objectGUID:: +OnN7n2DUkqCmpZFjspBdA==
    sAMAccountName: Users
    dn: CN=Investment Banker,CN=Users,DC=darranl,DC=jboss,DC=org
    objectClass: group
    cn: Investment Banker
    member: CN=Darran A. Lofthouse,CN=Users,DC=darranl,DC=jboss,DC=org
    memberOf: CN=Banker,CN=Users,DC=darranl,DC=jboss,DC=org
    name: Investment Banker
    objectGUID:: eGNw8LlNUUqSdhzs79MX2A==
    objectSid:: AQUAAAAAAAUVAAAAotmuNBRw7meCijOMUwQAAA==
    sAMAccountName: Investment Banker
    dn: CN=Banker,CN=Users,DC=darranl,DC=jboss,DC=org
    objectClass: group
    cn: Banker
    member: CN=Support User,OU=support,DC=darranl,DC=jboss,DC=org
    member: CN=Investment Banker,CN=Users,DC=darranl,DC=jboss,DC=org
    name: Banker
    objectGUID:: NGNZxgGCgkKdl+hbeLfpog==
    objectSid:: AQUAAAAAAAUVAAAAotmuNBRw7meCijOMUgQAAA==
    sAMAccountName: Banker
    dn: CN=Support User,OU=support,DC=darranl,DC=jboss,DC=org
    objectClass: group
    cn: Support User
    member: CN=Domain Users,CN=Users,DC=darranl,DC=jboss,DC=org
    name: Support User
    objectGUID:: 8bygyZ0um0GqhxBBOjXikg==
    objectSid:: AQUAAAAAAAUVAAAAotmuNBRw7meCijOMWgQAAA==
    sAMAccountName: Support User
    dn: CN=Support Admin,OU=support,DC=darranl,DC=jboss,DC=org
    objectClass: group
    cn: Support Admin
    member: CN=Darran A. Lofthouse,CN=Users,DC=darranl,DC=jboss,DC=org
    name: Support Admin
    objectGUID:: Lm3B93jxqEyCE9efPaeKig==
    sAMAccountName: Support Admin


    The group memberships can be seen as: -

    Active Directory Group Membership Diagram (2).png

    After authentication the user 'darranl' should be seen as being a member of the following groups: -

    • Domain User
    • Support User
    • Users
    • Investment Bank
    • Banker
    • Support Admin

    Example 2 - Free IPA

    The next example contains similar groups but this time was configured on a Free IPA installation.


    dn: uid=darranl,cn=users,cn=accounts,dc=darranl,dc=org
    displayName: Darran Lofthouse
    cn: Darran Lofthouse
    krbPrincipalName: darranl@DARRANL.ORG
    uid: darranl
    mepManagedEntry: cn=darranl,cn=groups,cn=accounts,dc=darranl,dc=org
    dn: cn=darranl,cn=groups,cn=accounts,dc=darranl,dc=org
    objectClass: posixgroup
    objectClass: mepManagedEntry
    cn: darranl
    mepManagedBy: uid=darranl,cn=users,cn=accounts,dc=darranl,dc=org
    dn: cn=investment_banker,cn=groups,cn=accounts,dc=darranl,dc=org
    objectClass: groupofnames
    objectClass: nestedgroup
    objectClass: ipausergroup
    objectClass: posixgroup
    cn: investment_banker
    member: uid=darranl,cn=users,cn=accounts,dc=darranl,dc=org
    dn: cn=banker,cn=groups,cn=accounts,dc=darranl,dc=org
    objectClass: groupofnames
    objectClass: nestedgroup
    objectClass: ipausergroup
    objectClass: posixgroup
    cn: banker
    member: cn=investment_banker,cn=groups,cn=accounts,dc=darranl,dc=org

    Like Active Directory there is also a single group assigned, this time it is assigned using the mepManagedEntry attribute.  Unlike Active Directory however this is a single static private group which is specific to the user.


    The following diagram illustrates the group membership for the user: -


    Free IPA Group Membership Diagram.png


    After authentication the user 'darranl' should be seen as being a member of the following groups: -

    • darranl
    • Investment_Banker
    • Banker




    Examples 1 and 2 both show that a group search can be performed by searching for all group objects with a member object referencing the users dn, however as illustrated in example 1 Active Directory has an option to optimise this as the user object also references it's groups so an expensive search can be skipped and instead focus on just loading specified attributes from specific dns.