CP 3 + Kerberos authentication

[morellik]

Dear all,

someone has some tips to use CP 3 with kerberos authentication?
I have an application that works well, authenticating the users via
shadow or db. Now I have to add the kerberos authentication.
How can intergrate CP with kerberos?

Thanks
Enrico

[pko...@gmail.com]

morellik schrieb:

Sorry for the delay. I hoped someone else could give you more information.

Now, what you write is a bit ambigous... Are you talking about HTTP
Authentication methods like BASIC or DIGEST? Or are you trying to do
plain old BASIC auth and want to verify credentails agains a
authentication source like shadow or a database?

In the former case, you'd have to implement GSS-SPNEGO in python which I
guess would be a lot of work. Apple has written some code to deal with
kerberos for their calendar server (a twisted based product) you should
have a look at their code if they do GSS-SPNEGO.

If you do BASIC auth and want to verify credentials against your KDC,
you might call kinit with the users name and password and see if you get
a ticket. This technique is highly discouraged as it exposes the
kerberos password on the wire and you should do this with https only.
Furthermore, this is not kerberos as in SSO, the user will still see the
password dialog, even if she already has valid tickets.

hth
Paul

[Sylvain Hellegouarch]

pko...@gmail.com a écrit :

I've never really looked at Kerberos but I was intrigued and had a quick
look at PyPI and found this:
http://pypi.python.org/pypi/pykpass/0.2

Would that be useful?

- Sylvain

[pko...@gmail.com]

Sylvain Hellegouarch schrieb:

I don't know but it does not *real* kerberos. The key point in kerberos
is not sending the password over the wire. Instead the client obtains a
service ticket for the http service from the KDC and sends this during
the http authentication process. The service itself has a trust
relationship with the KDC and is therefore able to verify the ticket.
The user isn't promted for a password at all if he obtained a TGT say
when he logged on to the workstation (fex windows domain).

cheers
Paul

[morellik]

Thanks to all,

I explain well my problem. I wrote an application in CP3 to launch
calculation,check jobs, navigate on user home (see files, remove file/
dirs, create file/dirs, put files, get files, create tarball, ecc) on
our cluster.

So, we have a new cluster that uses openafs/kerberos. In this case if
want to access to the user home, I have to give to the user the AFS
ticket otherwise the home is inaccessible.

My question is how can I give to any user his ticket from CP3?
I need a module that I can use to connect a ticket to a user session
(I'm wrong?).

I haven't idea how can do that. I also check the only two python
modules about kerberos (python-kerberos and python-krbV) but both
hasn't documentation.

Thanks
Enrico

[pko...@gmail.com]

morellik schrieb:

> Thanks to all,
>
> I explain well my problem. I wrote an application in CP3 to launch
> calculation,check jobs, navigate on user home (see files, remove file/
> dirs, create file/dirs, put files, get files, create tarball, ecc) on
> our cluster.

This sounds as if you're running the webserver as "root" or something
equivalent.

>
> So, we have a new cluster that uses openafs/kerberos. In this case if
> want to access to the user home, I have to give to the user the AFS
> ticket otherwise the home is inaccessible.

Can you provide a simple ASCII graph? What is a "user" here? And how ist
the that "user" supposed to access his "home" (which protocol)

> I haven't idea how can do that. I also check the only two python
> modules about kerberos (python-kerberos and python-krbV) but both
> hasn't documentation.

If AFS is just another kerberized service, you would need to forward the
TGT during the HTTP authentication so that your CP3 app would be able to
impersonate the user and obtain an AFS token on behalf of the user.

cheers
Paul

[morellik]

On Feb 8, 3:56 pm, "pkoe...@gmail.com" <pkoe...@gmail.com> wrote:
> morellik schrieb:> Thanks to all,
>
> > I explain well my problem. I wrote an application in CP3 to launch
> > calculation,check jobs, navigate on user home (see files, remove file/
> > dirs, create file/dirs, put files, get files, create tarball, ecc) on
> > our cluster.
>
> This sounds as if you're running the webserver as "root" or something
> equivalent.
>

Yes, the application runs like "root", for the moment.

>
>
> > So, we have a new cluster that uses openafs/kerberos. In this case if
> > want to access to the user home, I have to give to the user the AFS
> > ticket otherwise the home is inaccessible.
>
> Can you provide a simple ASCII graph? What is a "user" here? And how ist
> the that "user" supposed to access his "home" (which protocol)

An user is a real user. In normal cases, the user uses ssh to connect
to the remote machine. The remote machine require the user password
that will be authenticated by a kerberos server. If the authentication
is correct the user receive the ticket by kerberos server to enter in
his AFS home directory. To do that I changed the /etc/pam.d/ssh file
to enable the authentication via kerberos.

>
> > I haven't idea how can do that. I also check the only two python
> > modules about kerberos (python-kerberos and python-krbV) but both
> > hasn't documentation.
>
> If AFS is just another kerberized service, you would need to forward the
> TGT during the HTTP authentication so that your CP3 app would be able to
> impersonate the user and obtain an AFS token on behalf of the user.
>

How can I do that in CP3?


Thanks
Enrico

[pko...@gmail.com]

morellik schrieb:

>>> I haven't idea how can do that. I also check the only two python
>>> modules about kerberos (python-kerberos and python-krbV) but both
>>> hasn't documentation.
>> If AFS is just another kerberized service, you would need to forward the
>> TGT during the HTTP authentication so that your CP3 app would be able to
>> impersonate the user and obtain an AFS token on behalf of the user.
>>
> How can I do that in CP3?

You can't unless you implement the HTTP Negotiate protocol yoursef. Even
then you won't get delegation. As you don't do "real" kerberos your best
bet is to authenticate the user (ssl protected please) and fork off a
process, change to the users id and get an afs token. Then you should be
able to access the users home and get the results back to your cherrypy app.

hth
Paul
>
>
> Thanks
> Enrico

[morellik]

Ahi, ahi, ahi seems impossible to do for me. What I have to search to
do that? HTTP Negotiate?
Excuse me but I am not a programmer, I'm a sysadmin and I learned
Python myself. I write Python programs but in this case the problem i
very difficult for me.
I understand what you say but I have no idea how can implement it.

Can you give me more details?

Thanks a lot
Enrico

[pko...@gmail.com]

morellik schrieb:

>
>
> On Feb 13, 9:37 am, "pkoe...@gmail.com" <pkoe...@gmail.com> wrote:
>> morellik schrieb:
>>
>>>>> I haven't idea how can do that. I also check the only two python
>>>>> modules about kerberos (python-kerberos and python-krbV) but both
>>>>> hasn't documentation.
>>>> If AFS is just another kerberized service, you would need to forward the
>>>> TGT during the HTTP authentication so that your CP3 app would be able to
>>>> impersonate the user and obtain an AFS token on behalf of the user.
>>> How can I do that in CP3?
>> You can't unless you implement the HTTP Negotiate protocol yoursef. Even
>> then you won't get delegation. As you don't do "real" kerberos your best
>> bet is to authenticate the user (ssl protected please) and fork off a
>> process, change to the users id and get an afs token. Then you should be
>> able to access the users home and get the results back to your cherrypy app.
>>
>> hth
>> Paul
>
> Ahi, ahi, ahi seems impossible to do for me. What I have to search to
> do that? HTTP Negotiate?

Probably. You can read RFC 4559 and friends, but given the situation I'd
recommend against pursuing this option.

> Excuse me but I am not a programmer, I'm a sysadmin and I learned
> Python myself.

Me too ;)

> I write Python programs but in this case the problem i
> very difficult for me.
> I understand what you say but I have no idea how can implement it.
>
> Can you give me more details?

Not much, I know too little about AFS. In kerberos, the context for
credentials is "per process" and while you can get multiple tickets at
the same time, selection of the "right" ticket might be problematic.

Again, plain kerberos allows you to get a ticket and store it in a file,
then you can use it later (example with ldap service):

> kinit -c foo_ccache
> kinit -c bar_ccache

> KRB5CCNAME=foo_cache ldapsearch
SASL/GSSAPI authentication started
SASL username: f...@REALM.COM
SASL SSF: 56
SASL installing layers

> KRB5CCNAME=bar_cache ldapsearch
SASL/GSSAPI authentication started
SASL username: b...@REALM.COM
SASL SSF: 56
SASL installing layers

If AFS allows to store the token in a file and set a ENV variable then
you can use the same approach. If not, you need one seperate process per
user where you call whatever command gets you the AFS token. That is:

user:pass -> HTTPS -> CP3 -> Popen("klog username@cell; command1;
command2;)

Note that klog might not have an option to give the password on the
commandline. With the Popen() call you need to run klog for each and
every operation again (not so good).
The other option is to actually fork() a long running process for each
user and use some kind of IPC to get the results. This is probably
harder but scales better if you have not that many users but many calls
to the service.

cheers
Paul

[Sylvain Hellegouarch]

Can't remember if you discussed that option but you might also put an
Apache instance in front of CherryPy and let it handle the Kerberos
authentication.

http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/

- Sylvain

pko...@gmail.com a écrit :

[pko...@gmail.com]

Sylvain Hellegouarch schrieb:

> Can't remember if you discussed that option but you might also put an
> Apache instance in front of CherryPy and let it handle the Kerberos
> authentication.
>
> http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/

In case you just want to use AD or some other KDC for authorization this
is fine. However, kerberos can do more:

- Impersonation, where the webserver does something with the identity of
the connected user, (e.g. running ASP code).
- Delegation, where the webserver reuses the identity of the client to
connect to a third server, (e.g. query a database).

Unfortunately the OP needs delegation to have the webserver talk to AFS
with the clients identiy. Now that we know the OP doesn't do "real"
kerberos, (even in the ssh case the client doesn't have a ticket
*before* connecting via ssh), there is no point trying to implement
delegation.

back to good old unix hackery ;)

cheers
Paul

[Sylvain Hellegouarch]

pko...@gmail.com a écrit :

Thanks for sharing your experience in that area. I was not well aware of
all the dirty secrets of Kerberos.

- Sylvain

[Tim Roberts]

Sylvain Hellegouarch wrote:

Thanks for sharing your experience in that area. I was not well aware of 
all the dirty secrets of Kerberos.
  

Is that a pun?  ;)

-- 
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Sylvain Hellegouarch]

Tim Roberts a écrit :

> Sylvain Hellegouarch wrote:
>>
>> Thanks for sharing your experience in that area. I was not well aware of
>> all the dirty secrets of Kerberos.
>>
>
> Is that a pun? ;)

If I can make puns without noticing them and in a foreign language then
my life is complete. In a nutsheel it was one I didn't do it on purpose :)

- Sylvain