Difference between revisions of "Projects/KerberosDelegationACL"

Revision as of 02:08, 13 April 2014

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

Background

Customers would like greater access controls for constrained delegation. The current implementation provides ACLs for S4U2Proxy requests to restrict which target services the KDC can issue for proxy principals, but does not have provisions for which user principals that the proxy principal can request service tickets on behalf of.

Design

The proposed solution is implemented in the LDAP back-end only. The proposed attributes and classes are:

attributeTypes: ( 2.16.840.1.113730.3.8.11.20
        NAME 'memberPrincipal'
        DESC 'Principal names member of a groupOfPrincipals group'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

objectClasses: ( 2.16.840.1.113730.3.8.12.6
        NAME 'groupOfPrincipals'
        SUP top AUXILIARY
        MUST ( cn )
        MAY ( memberPrincipal ))

attributeTypes: ( 2.16.840.1.113730.3.8.11.21
         NAME 'AllowToImpersonate'
         DESC 'Principals that can be impersonated'
         SUP distinguishedName)

attributeTypes: ( 2.16.840.1.113730.3.8.11.22
         NAME 'AllowedTarget'
         DESC 'Target principals alowed to get a ticket for'
         SUP distinguishedName)

objectClasses: ( 2.16.840.1.113730.3.8.12.7
        NAME 'Krb5DelegationACL'
        SUP groupOfPrincipals STRUCTURAL
        MAY ( AllowToImpersonate $ AllowedTarget ))

Groupings are proposed given that one instance could be used across multiple entries instead of having to define these multiple times for each entry.

groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.

Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance. We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.

This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control). The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.

We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.

The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.

Use Cases

The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal. Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data. This assumes a non-cross realm environment.

This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals. This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.

Example

We want to allow our HTTP server cluster to impersonate 2 users (shawn and simo) against the LDAP server cluster:

First we create a group of users:

dn: cn=allowed-users,SUFFIX
objectclass: groupOfPrincipals
cn: cn=allowed-users
memberPrincipal: shawn@KERBEROS.ORG
memberPrincipal: simo@KERBEROS.ORG

Then a group of target servers (we assume there may be multiple copies all equally accessible):

dn: cn=LDAP-Servers,SUFFIX
objectclass: groupOfPrincipals
cn: LDAP-Servers
memberPrincipal: ldap/ldap-server-1.kerberos.org@KERBEROS.ORG
memberPrincipal: ldap/ldap-server-2.kerberos.org@KERBEROS.ORG

Finally we create the allow rule which binds clients, targets, and the proxy service:

dn: cn=http-ldap-delegation,SUFFIX
objectclass: groupOfPrincipals
objectclass: Krb5DelegationACL
cn: http-ldap-delegation
AllowToImpersonate: cn=allowed-users,SUFFIX
AllowedTarget: cn=LDAP-Servers,SUFFIX
memberPrincipal: HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG

Difference between revisions of "Projects/KerberosDelegationACL"

Revision as of 02:08, 13 April 2014

Navigation menu

Views

Personal tools

Navigation

Search

Tools

@@ Line 40: / Line 40: @@
 groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.
+Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance.  We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.
+This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control).  The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.
+We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.
+The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.
+'''Use Cases'''
+The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal.  Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data.  This assumes a non-cross realm environment.
+This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals.  This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.
 '''Example'''
@@ Line 72: / Line 86: @@
  memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
  memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG
-Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. We haven't implemented it yet but also you could have regexes in memberPrincipal for additional flexibility.
-This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control).  The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.
-We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.
-The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.