Restricting proxied authorization for specific users - PingDirectory - 9.0

PingDirectory

bundle
pingdirectory-90
ft:publication_title
PingDirectory
Product_Version_ce
PingDirectory 9.0
category
Product
pd-90
pingdirectory
ContentType_ce

Use the following example scenario with proxied users to restrict proxied authoriation.

To illustrate how the proxied authorization operational attributes work, set up a simple example where two LDAP clients, uid=clientApp1 and uid=clientApp2uid=admin1 and uid=admin2. Add the , can freely proxy two administrator accounts, ds-auth-may-proxy-as-* and ds-auth-is-proxyable-* attributes to these entries to restrict how each account can use proxied authorization.

For example, the two client applications can continue to proxy the uid=admin1 account but the uid=admin2 account are no longer able to be used as a proxied entry.

Proxy Users Example Scenario

A flowchart showing an example configuration of restricting proxied authorization for specific users. In the first configuration, both client apps can proxy as either of the admins to perform operations. In the second configuration, both client apps must proxy as the first admin to perform operations.
  1. Set up two user entries, uid=clientApp1, can freely proxy two administrator accounts, and uid=clientApp2, with the proxied-auth privilege assigned to them.

    The user entries will proxy as the uid=admin1 and uid=admin2 accounts to access the ou=People,dc=example,dc=com subtree.

    1. Open a text editor and create an LDIF file.
    2. Add the file using the ldapmodify tool.
    Note:

    In this example, indicates that other attributes present in the entry are not included for readability purposes.

    dn: uid=clientApp1,ou=Applications,dc=example,dc=com    
    objectClass: top    
    ...
    ds-privilege-name: proxied-auth
    
    dn: uid=clientApp2,ou=Applications,dc=example,dc=com    
    objectClass: top    
    ...
    ds-privilege-name: proxied-auth
  2. Assign the access control instruction (ACI) for each client application to the subtree, ou=People,dc=example,dc=com.
    Note:

    ACIs should be on one line of text. The following example displays ACIs over multiple lines for readability.

    dn: ou=People,dc=example,dc=com    
    aci: (version 3.0; acl "People Proxy Access"; allow(proxy)
           userdn="ldap:///uid=clientApp1,ou=Applications,dc=example,dc=com";)  
    aci: (version 3.0; acl "People Proxy Access"; allow(proxy)
           userdn="ldap:///uid=clientApp2,ou=Applications,dc=example,dc=com";)
  3. Run a search for each entry.

    In this example, assume that there are two admin accounts, admin1 and admin2, that have full access rights to user attributes. You should be able to proxy as the uid=admin1 and uid=admin2 entries to access the subtree for both clients.

    $ bin/ldapsearch --port 1389 \ 
      --bindDN "uid=clientApp1,ou=Applications,dc=example,dc=com" \    
      --bindPassword password \
      --proxyAs "dn:uid=admin1,dc=example,dc=com" \    
      --baseDN ou=People,dc=example,dc=com \    
      "(objectclass=*)"  
                  
    $ bin/ldapsearch --port 1389 \    
      --bindDN "uid=clientApp2,ou=Applications,dc=example,dc=com" \
      --bindPassword password \
      --proxyAs "dn:uid=admin2,dc=example,dc=com" \ 
      --baseDN ou=People,dc=example,dc=com \ 
      "(objectclass=*)"
  4. Limit the proxied authorization capabilities for each client application.

    In the following example, the ds-auth-may-proxy-as attribute specifies that uid=clientApp1 can proxy as the uid=admin1 entry.

    1. Open a text editor and create the following LDIF file.
    2. Update the uid=clientApp1 entry to add the ds-auth-may-proxy-as attribute.
      Note:

      ds-auth-may-proxy-as is multi-valued.

    3. Save the file and add it using ldapmodify.
    dn: uid=clientApp1,ou=Applications,dc=example,dc=com
    changetype: modify
    add: ds-auth-may-proxy-as    
    ds-auth-may-proxy-as: uid=admin1,dc=example,dc=com  
  5. Repeat the previous step for the uid=clientApp2 entry, but specify the ds-auth-may-proxy-as-url attribute.

    The client entry can proxy as any distinguished name (DN) that matches the LDAP URL.

    dn: uid=clientApp2,ou=Applications,dc=example,dc=com 
    changetype: modify 
    add: ds-auth-may-proxy-as-url 
    ds-auth-may-proxy-as-url: ldap:///dc=example,dc=com??sub?(uid=admin*)  
  6. To illustrate the ds-auth-proxyable-by-group attribute, create a group of client applications that has uid=clientApp1 and uid=clientApp2 as its uniquemembers.

    This example sets up a static group using the groupOfUniqueNames object class.

    dn: ou=Groups,dc=example,dc=com    
    objectClass: top    
    objectClass: organizationalunit    
    ou: groups
      
    dn: cn=Client Applications,ou=Groups,dc=example,dc=com    
    objectClass: top
    objectClass: groupOfUniqueNames    
    cn: Client Applications  
    ou: groups    
    uniquemember: uid=clientApp1,ou=Applications,dc=example,dc=com
    uniquemember: uid=clientApp2,ou=Applications,dc=example,dc=com    
  7. Update the uid=admin1 entry to provide the DN that it can be proxied as.
    1. Open a text editor and create the following LDIF file.
    2. Use the ds-auth-is-proxyable to make the uid=admin1 a required proxyable entry, meaning that it can only be accessed by some form of proxied authorization.
    3. Use the ds-auth-is-proxyable-by attribute to specify each DN that can proxy as uid=admin1.
    4. Save the LDIF file and add it using ldapmodify.
    dn: uid=admin1,dc=example,dc=com    
    changetype: modify
    add: ds-auth-is-proxyable
    ds-auth-is-proxyable: required  
    - 
    add: ds-auth-is-proxyable-by 
    ds-auth-is-proxyable-by: ou=clientApp1,ou=Applications,dc=example,dc=com 
    ds-auth-is-proxyable-by: ou=clientApp2,ou=Applications,dc=example,dc=com 
    - 
    add: ds-auth-is-proxyable-by-group 
    ds-auth-is-proxyable-by-group: cn=Client Applications,ou=Groups,dc=example,dc=com 
    - 
    add: ds-auth-is-proxyable-by-url 
    ds-auth-is-proxyable-by-url: ldap:///ou=Applications,dc=example,dc=com??sub?(uid=clientApp*)
    Note:

    The example includes all three types of ds-auth-is-proxable-by-* attributes as an illustration, but only one type of attribute is necessary if they all target the same entries.

  8. Prohibit proxying for the uid=admin2 entry.
    1. Open a text editor and create the following LDIF file.
    2. Set the ds-auth-is-proxyable attribute to prohibited.
    3. Save the LDIF file and add it using ldapmodify.
    dn: uid=admin2,dc=example,dc=com
    changetype: modify
    add: ds-auth-is-proxyable
    ds-auth-is-proxyable: prohibited  
  9. Run a search using the proxied account.
    1. To return a successful operation, run a search with uid=clientApp1 or uid=clientApp2 that proxies as uid=admin1.
    2. To return an unsuccessful operation, run a search for uid=clientApp1 that proxies as uid=admin2.
    $ bin/ldapsearch --port 1389 \    
      --bindDN "uid=clientApp1,ou=Applications,dc=example,dc=com" \    
      --bindPassword password \
      --proxyAs "dn:uid=admin2,dc=example,dc=com" \    
      --baseDN ou=People,dc=example,dc=com \
      "(objectclass=*)"

    The operation is unsuccessful because uid=admin2 does not match the list of potential entries that can be proxied. The ds-auth-may-proxy-as-* attributes specify that the client can only proxy as uid=admin1.

    One of the operational attributes (ds-auth-may-proxy-as,
    ds-auth-may-proxy-as-group, ds-auth-may-proxy-as-url) in user entry 
    'uid=clientApp1,ou=Applications,dc=example,dc=com' does not allow
    that user to be proxied as user 'uid=admin2,dc=example,dc=com'
    
    Result Code: 123 (Authorization Denied)
    
    Diagnostic Message: One of the operational attributes (ds-auth-may-proxy-as,
    ds-auth-may-proxy-as-group, ds-auth-may-proxy-as-url) in user entry
    'uid=clientApp1,ou=Applications,dc=example,dc=com' does not allow that
    user to be proxied as user 'uid=admin2,dc=example,dc=com'
  10. Run another search using uid=clientApp2, which attempts to proxy as uid=admin2.
    $ bin/ldapsearch --port 1389 \    
      --bindDN "uid=clientApp2,ou=Applications,dc=example,dc=com" \    
      --bindPassword password \
      --proxyAs "dn:uid=admin2,dc=example,dc=com" \    
      --baseDN ou=People,dc=example,dc=com \  
      "(objectclass=*)"

    The operation is unsuccessful because the ds-auth-is-proxyable:prohibited operational attribute states that uid=admin2 is not available for proxied authorization.

    The 'ds-auth-is-proxyable' operational attribute 
    in user entry 'uid=admin2,dc=example,dc=com' indicates that
    user may not be accessed via proxied authorization
    
    Result Code: 123 (Authorization Denied)
    
    Diagnostic Message: The 'ds-auth-is-proxyable' operational
    attribute in user entry 'uid=admin2,dc=example,dc=com' indicates
    that user may not be accessed via proxied authorization