Bug 734753

Thanks for your suggestion. However, this refers to the deployment and according to redhat security policy, it does not allow to do that way.

(In reply to comment #1)
> Thanks for your suggestion. However, this refers to the deployment and
> according to redhat security policy, it does not allow to do that way.

This sounds strange, bugzilla is using exactly this approach, authenticate once, then use cookie to keep authorized session. I don't think that bugzilla is not in accordance with security policy.

Could you point me to that policy?
If it really says we can't use session cookies, it's the best time to contact it's author and convince him otherwise :)

(In reply to comment #2)
> (In reply to comment #1)
> > Thanks for your suggestion. However, this refers to the deployment and
> > according to redhat security policy, it does not allow to do that way.
> 
> This sounds strange, bugzilla is using exactly this approach, authenticate
> once, then use cookie to keep authorized session. I don't think that bugzilla
> is not in accordance with security policy.

My reply is mainly aimed at this point "If you turn it off for the whole site except a login page". Bugzilla does not use Kerberos authentication. This is different from the what TCMS does.

(In reply to comment #3)
> Could you point me to that policy?
> If it really says we can't use session cookies, it's the best time to contact
> it's author and convince him otherwise :)

https://home.corp.redhat.com/wiki/information-security

I mean that to turn off HTTPS does not follow the policy.

This is not request to turn off https, authentication or authorization. nobody asked for that.

This request is about reducing amount of http auth requests. Session cookie can be assigned to the user based on successful http authentication, this cookie can be used for further authorization. If request without valid cookie arrives http auth is requested again.

This is common approach used by many sites, as an advance it will significantly improve response of tcms.

It's not about turning HTTPS off completely.
I proposed to turn kerberos off except the login page.

Typical workflow:
 1) user visits web page via *HTTPS*
 2) no session cookie -> redirect to a *kerberized* login page
 3) session cookie is created
 4) redirect back to the original address, no kerberos auth used, only the valid session cookie

(In reply to comment #7)
> It's not about turning HTTPS off completely.
> I proposed to turn kerberos off except the login page.
> 
> Typical workflow:
>  1) user visits web page via *HTTPS*
>  2) no session cookie -> redirect to a *kerberized* login page
>  3) session cookie is created
>  4) redirect back to the original address, no kerberos auth used, only the
> valid session cookie

I known this workflow, that is a normal workflow for authenticating subsequent requests in a Web app. You really pointed out an aspect that we should pay more attention. Thanks again.

(In reply to comment #0)
> According to Nitrate sources, everything under '/' location is kerberized
> (KrbMethodNegotiate on).
> 
> If you turn it off for the whole site except a login page and use a session
> cookie to authenticate on other places, it will significantly boost overall
> performance.
> 
> 
> If you want to know more details, let me know.
> I've implemented auth this way in several tools and it really helped.

If client's Web browser, like Firefox, does not turn negotiation mode, each request is authenticated by HTTP Basic authentication mechanism, thus there is only one step to authenticate client.

(In reply to comment #9)
> If client's Web browser, like Firefox, does not turn negotiation mode, each
> request is authenticated by HTTP Basic authentication mechanism, thus there
> is only one step to authenticate client.

Basic authentication doesn't seem to be sufficient as it requires kerberos password sent in plain text. We all turn on Negotiate because of 2 reasons: comfort and security.

ping, any progress on this?

We are investigating the performance improvement solutions for tcms 4.0. Your suggestion is one of the solutions, we need eng-ops confirmation on this solution. If they agree, we will implement it in tcms 4.0, along with other solutions.
Will update the confirmation with eng-ops.