Constrained Delegation

[Simo Sorce]

On Sun, 2013-09-08 at 00:17 -0600, Shawn M Emery wrote:
> Hi Simo,
> 
> Thank you for your thorough response to this problem space.  I was also 
> looking into a nested group type solution, as the use-cases around this 
> evolves.  Do you have any plans in contributing this schema to the 
> trunk, as there has been precedence for constrained delegation?  I would 
> obviously volunteer to help in any work in this area if approved.

I am certainly willing to do that, the main reason I did not so far is
that there would not be any kadmin interface to do that.

However if it is ok to have something just in the MIT LDAP driver, that
can't be managed via kadmin I can certainly help bringing the relevant
code upstream.

Would you be ok using the same objectslasses and attributes we create in
IPA ? Or would MIT want to have differently named ones in the schema ?

I guess we could also make the attributes/objectclasses paramtetrized so
that names can be changed at will by the specific deployment.

Simo.


> Regards,
> 
> Shawn.
> --
> On 09/ 7/13 12:07 PM, Simo Sorce wrote:
> > On Sat, 2013-09-07 at 00:59 -0600, Shawn M Emery wrote:
> >> We were wanting to provide additional checks beyond constrained
> >> delegations where the proxy principal has access controls associated for
> >> which client principals are allowed to be delegated from.  I know that
> >> this could be controlled by creating authz data that the subsequent
> >> target service can check, but this seems rather inefficient in a
> >> non-cross-realm case in which the KDC can easily make these policy checks.
> >>
> >> My draft proposal includes a new LDAP attribute of the proxy principal:
> >>
> >>       krbAllowedToDelegateFor
> >>
> >> which would define the various client principals in which the proxy
> >> principal is allowed to delegate for.  Perhaps this could be tied into
> >> group memberships in order to reduce redundant definitions across proxy
> >> principals.  The ordering of checks by the KDC would be to check to make
> >> sure that the target principal is in the krbAllowedToDelegateTo set and
> >> if so then infer the krbAllowedToDelegateFor for the client principal.
> >> If not defined then then fall-back to the existing behavior of success
> >> else if the client is found in the krbAllowedToDelegateFor set then
> >> succeed else fail.  The pseudo-code would like the following:
> >>
> >>       {DelegateTo} == proxy && {DelegateFor} == client -> succeed
> >>       {DelegateTo} == proxy && {DelegateFor} == NULL -> succeed
> >>       {DelegateTo} == proxy && {DelegateFor} != client -> fail
> >>
> >> The code-points would entail the following:
> >>
> >> /* Constrained delegation for */
> >> #define KRB5_KDB_FLAG_CONSTRAINED_DELEGATION_4 0x00000400
> >> #define KRB5_KDB_FLAGS_S4U \
> >>     ( KRB5_KDB_FLAG_PROTOCOL_TRANSITION |
> >> KRB5_KDB_FLAG_CONSTRAINED_DELEGATION | \
> >>       KRB5_KDB_FLAG_CONSTRAINED_DELEGATION_4 )
> >>
> >> #define KRB5_TL_CONSTRAINED_DELEGATION4_ACL 0x0700 /* Each entry is a
> >> permitted UPN */
> >>
> >> ##### A list of principals to which a service principal can delegate for.
> >> dn: cn=schema
> >> changetype: modify
> >> add: attributetypes
> >> attributetypes:  ( 1.3.6.1.4.1.5322.21.2.4
> >>                   NAME 'krbAllowedToDelegateFor'
> >>                   EQUALITY caseExactIA5Match
> >>                   SUBSTR caseExactSubstringsMatch
> >>                   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)
> >>
> >> I just wanted to get your thoughts on the idea before I consider this
> >> further.
> >
> > Hi Shawn, we've address this problem in FreeIPA using a slightly more
> > complex scheme in order to be able to handle groupings which makes the
> > feature actually usable (having to list all principals in multiple rules
> > quickly becomes unmaintainable).
> >
> > We added 3 attributes and 2 objectclasses:
> >
> > 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 X-ORIGIN 'IPA-v3')
> > objectClasses: ( 2.16.840.1.113730.3.8.12.6
> > 		 NAME 'groupOfPrincipals'
> > 		 SUP top AUXILIARY
> > 		 MUST ( cn )
> > 		 MAY ( memberPrincipal )
> > 		 X-ORIGIN 'IPA v3' )
> >
> > attributeTypes: ( 2.16.840.1.113730.3.8.11.21
> > 		  NAME 'ipaAllowToImpersonate'
> > 		  DESC 'Principals that can be impersonated'
> > 		  SUP distinguishedName X-ORIGIN 'IPA-v3')
> > attributeTypes: ( 2.16.840.1.113730.3.8.11.22
> > 		  NAME 'ipaAllowedTarget'
> > 		  DESC 'Target principals alowed to get a ticket for'
> > 		  SUP distinguishedName X-ORIGIN 'IPA-v3')
> > objectClasses: ( 2.16.840.1.113730.3.8.12.7
> > 		 NAME 'ipaKrb5DelegationACL'
> > 		 SUP groupOfPrincipals STRUCTURAL
> > 		 MAY ( ipaAllowToImpersonate $ ipaAllowedTarget )
> > 		 X-ORIGIN 'IPA v3' )
> >
> > The way it works is by creating first a groupOfPrincipals (may contain a
> > single principal) for clients and targets, and then joining all together
> > into an 'ACL object'.
> >
> > 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 at KERBEROS.ORG
> > memberPrincipal: simo at 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 at KERBEROS.ORG
> > memberPrincipal: ldap/ldap-server-2.kerberos.org at KERBEROS.ORG
> >
> > Finally we create the allow rule which binds clients, targets and the
> > proxying service:
> >
> > dn: cn=http-ldap-delegation,SUFFIX
> > objectclass: groupOfPrincipals
> > objectclass: ipaKrb5DelegationACL
> > cn: http-ldap-delegation
> > ipaAllowToImpersonate: cn=allowed-users,SUFFIX
> > ipaAllowedTarget: cn=LDAP-Servers,SUFFIX
> > memberPrincipal: HTTP/http-proxy-1.kerberos.org at KERBEROS.ORG
> > memberPrincipal: HTTP/http-proxy-2.kerberos.org at KERBEROS.ORG
> > memberPrincipal: HTTP/http-proxy-3.kerberos.org at KERBEROS.ORG
> >
> >
> > Note that in our schema lack of ipaAllowToImpersonate 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).
> >
> > 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 kadimn could be extended so that it is
> > flexible enough to allow this kind of representation.
> >
> > HTH,
> > Simo.


-- 
Simo Sorce * Red Hat, Inc * New York