> Oh, wait, negotiate is built into CoSign, sorry, I misread that
> part.

Hmm, no, wait, now I'm reading that you have to run mod_auth_kerb too, 
and that requires Negotiate-Auth, and the negotiate keyword in cosign 
just checks REMOTE_USER set by mod_auth_kerb, it doesn't do the 
negotiate itself.

What I want is normal browser users to do the normal cosign form with 
password entry, but my services to be able to shortcut around that by 
using kerberos/spnego directly.  It doesn't seem possible to make the 
negotiate-auth part optional, like an SSL client certificate is, right?

In other words, in the normal spnego flow chart, the client requests, 
gets a 401, and then does the authn.  I can just have my services 
directly send the spnego auth token in the GET, but I need the server to 
not 401 if it's not there, just pretend like everything's a normal 
cosign login.

You've got your js negotiate checker, but that's a browser thing, I want 
to have it just be completely optional.

Make sense?

Chris


On 2011/07/31 20:55, Chris Hecker wrote:
>
> Oh, wait, negotiate is built into CoSign, sorry, I misread that part.
>
> Hmm, I will have to play around with this.
>
> Chris
>
>
> On 2011/07/31 13:44, Chris Hecker wrote:
>>
>>> 5. Provide a Kerberos protected version of the cosign login CGI. This
>>> allows applications to authenticate using NegotiateAuth, get cosign
>>> cookies, and then continue onwards as a cosign'd service. We also
>>> provide this to users who are using supported browsers (mainly
>>> Firefox) on managed machines, so that we avoid the Web-Double-Signon
>>> problem.
>>
>> Did you put your patches for this up? I see your mod_auth_krb one, but
>> nothing for CoSign?
>>
>> So this is transparent to browser users? In other words, I want my
>> browser people to just do the cosign login that talks to krb5, but I
>> want to talk to the cosign pages with negotiateauth from code.
>>
>> Thanks,
>> Chris
>>
>>
>>
>> On 2011/07/31 05:28, Simon Wilkinson wrote:
>>>
>>> On 31 Jul 2011, at 06:07, Chris Hecker wrote:
>>>> 3. Set up and use kx509 so the services can get short term x.509
>>>> certificates. This seems like the best one, but...is the kx509 project
>>>> still being developed? The public source code hasn't been touched since
>>>> 2005. This post talks about being wary of its code quality (at least,
>>>> KCT's quality):
>>>>
>>>> http://orthrus.blogspot.com/2007/10/kx509-kerberos-and-cosign.html
>>>
>>> I wrote that. KCT is horrible. kx509 is nicer. We are still running
>>> kx509 locally, but it's increasingly a service in search of
>>> applications. At the moment all we use it for is getting client
>>> certificates for OpenVPN. Cosign has completely supplanted it for web
>>> authentication at most sites that I am aware of. kx509 does still have
>>> some traction - there is native support in Heimdal, for example, and
>>> Henry Hotz is working on specifying an improved version of the
>>> protocol. It's still probably not the best solution for this problem,
>>> though.
>>>
>>>> 4. Write a custom kerberized proxy for just the pages I need, services
>>>> make normal krb5 requests to that, and it runs on the webserver. Yuck.
>>>
>>> Yuck indeed. What we do is ...
>>>
>>> 5. Provide a Kerberos protected version of the cosign login CGI. This
>>> allows applications to authenticate using NegotiateAuth, get cosign
>>> cookies, and then continue onwards as a cosign'd service. We also
>>> provide this to users who are using supported browsers (mainly
>>> Firefox) on managed machines, so that we avoid the Web-Double-Signon
>>> problem.
>>>
>>> I blogged about this in 2007 -
>>> http://orthrus.blogspot.com/2007/10/kx509-kerberos-and-cosign.html
>>>
>>> Hope that helps!
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>>

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Cosign-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Reply via email to