[Freeipa-devel] another snag with kerberos

[Andrew Bartlett]

On Thu, 2007-07-19 at 08:49 -0400, Karl MacMillan wrote:
> On Thu, 2007-07-19 at 12:08 +1000, Andrew Bartlett wrote:
> > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote:
> > > Karl MacMillan wrote:
> > > > On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote:
> > > >> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote:
> > > >>> I don't see a way to add headers to the client request using xmlrpclib.py.
> > > >> I took a quick look at xmlrpclib.py. I agree there does not seem to be a
> > > >> way to add headers in the exported API. However, it's not a complicated
> > > >> module and fairly cleanly written so it looks like it would be
> > > >> relatively easy to edit the the module and add the authentication
> > > >> functionality. This would mean the IPA implementation would have it's
> > > >> own private copy of the module but I suspect once it's working a diff
> > > >> against the original sent as a patch to upstream would be most welcome
> > > >> and then at a later date you can nuke your private copy once upstream
> > > >> ships the fix.
> > > > 
> > > > Not ideal - but seems workable. Rob - any other options or is this the
> > > > way you want to go?
> > > > 
> > > > Karl
> > > > 
> > > 
> > > After looking at this some more I wonder if we could simply subclass the 
> > > Transport method and include the headers that way. I'm not enough of a 
> > > python expert to know how large a task this would be.
> > > 
> > > In any case we can't do anything until we find a way to do kerberos SSO 
> > > with ticket forwarding using some sort of HTTP engine. 
> > 
> > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I
> > wonder if for IPAv1 we should instead have the XMLRPC server simply be
> > trusted?  (Bind as EXTERNAL, then do LDAP proxy authorization). 
> > 
> 
> Maybe I don't understand, but are you suggesting that the LDAP database
> not know the user identity? So the xmlrpc server would connect using a
> single identity?

That's the Samba approach, but no, that's not what I propose. 

> We got to where we are today because we didn't want to recreate the
> access control layer that exists in the LDAP server in our xmlrpc
> server. 

Indeed. 

> So if what you're suggesting is the above then I would rather
> avoid that.

If the intermediary can say 'I've proved myself trusted over ldapi://,
then use ldap proxy authorization to assert that this operation occurs
as <origianal user dn>.

The con is that this intermediary can effectively become any user in the
directory (by assertion, if compromised). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20070720/94cea9cb/attachment.sig>