[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577354#comment-16577354
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 10:25 PM:
-
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
AFter this token is used once, the token no longer works.
How does this have anything to do with HTTP client? I'm not making that
connection.
was (Author: ndipiazza_gmail):
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
Once used once, the token no longer works.
How does this have anything to do with HTTP client? I'm not making that
connection.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577354#comment-16577354
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 10:24 PM:
-
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
Once used once, the token no longer works.
How does this have anything to do with HTTP client? I'm not making that
connection.
was (Author: ndipiazza_gmail):
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
Once used once, the token no longer works until re-established.
How does this have anything to do with HTTP client? I'm not making that
connection.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577354#comment-16577354
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 10:24 PM:
-
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
Once used once, the token no longer works until re-established.
How does this have anything to do with HTTP client? I'm not making that
connection.
was (Author: ndipiazza_gmail):
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
How does this have anything to do with HTTP client? I'm not making that
connection.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577354#comment-16577354
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 10:22 PM:
-
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library.
{{org.ietf.jgss}} and {{java.security.auth}} packages only.
Once I have this token I can just set it as a header on any request even with
postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
How does this have anything to do with HTTP client? I'm not making that
connection.
was (Author: ndipiazza_gmail):
I'm confused. I'm not using HttpClient's auth configs at all. I'm just
generating my own Negotiate token using the JRE's GSS library. Once I have this
token I can just set it as a header on any request even with postman.
For example it generates a token like
{code}
YIILJAYGKwYBBQUC30XYySHNMJ
{code}
Then i can make an http request like this with curl even:
{code}
curl -H "authorization: Negotiate YIILJAYGKwYBBQ...tzbIo5FHxr30XYySHNMJ"
http://myhost:81/10.html
{code}
How does this have anything to do with HTTP client? I'm not making that
connection.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577349#comment-16577349
]
Michael Osipov edited comment on HTTPCLIENT-1912 at 8/11/18 10:21 PM:
--
I believe that with the client 4.x it is hardly possible to make this right
(complete the security context). I started some notes on our wiki:
https://wiki.apache.org/HttpComponents/IssueTracking/HTTPCLIENT-1625.
Here is the impl:
https://github.com/apache/serf/blob/trunk/auth/auth_spnego_gss.c, here the
description: https://github.com/apache/serf/blob/trunk/auth/auth_spnego.h and
https://github.com/apache/serf/blob/trunk/auth/auth_spnego.c.
This is the only open source implemenation I know which does it right, except
Chrome and Firefox.
If you compile serf from source, you can do {{scons test}} and it will generate
{{serf_get}}. It has a detailed debug mode which will show you that is has
successfully completed the security context. It works well with IIS, Forefront
TMG, HTTPd with mod_auth_gssapi as well as Tomcat with my SPNEGO authenticator.
was (Author: michael-o):
I believe that with the client 4.x it is hardly possible to make this right
(complete the security context). I started some notes on our wiki:
https://wiki.apache.org/HttpComponents/IssueTracking/HTTPCLIENT-1625.
Here is the impl:
https://github.com/apache/serf/blob/trunk/auth/auth_spnego_gss.c, here the
description: https://github.com/apache/serf/blob/trunk/auth/auth_spnego.h and
https://github.com/apache/serf/blob/trunk/auth/auth_spnego.c.
This is the only open source implemenation I know which does it right, except
Chrome and Firefox.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577347#comment-16577347
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 10:08 PM:
-
Yeah I've noticed something that is this hard to understand once it "works"
(meaning lets you authenticate and make authenticated http requests to get the
content you need), people shrug off issues with the security because they don't
care.
Can you possibly help me out a little by highlighting some changes to make to
my {{SpnegoAuth}} class to fix the issues? Or is it so far off that I wasted my
time here?
Or could you possibly highlight where in particular libserf does this
correctly?
I'm using only Java Security code here. I'm not doing anything with HTTP client
anymore with regards to the auth.
was (Author: ndipiazza_gmail):
Yeah I've noticed something that is this hard to understand once it "works"
(meaning lets you authenticate and make authenticated http requests to get the
content you need), people shrug off issues with the security because they don't
care.
Can you possibly help me out a little by highlighting some changes to make to
my {{SpnegoAuth}} class to fix the issues? Or is it so far off that I wasted my
time here?
Or could you possibly highlight where in particular libserf does this
correctly?
I'm using only Java Security code here. I'm not doing anything with HTTP client
anymore.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577347#comment-16577347
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 10:08 PM:
-
Yeah I've noticed something that is this hard to understand once it "works"
(meaning lets you authenticate and make authenticated http requests to get the
content you need), people shrug off issues with the security because they don't
care.
Can you possibly help me out a little by highlighting some changes to make to
my {{SpnegoAuth}} class to fix the issues? Or is it so far off that I wasted my
time here?
Or could you possibly highlight where in particular libserf does this
correctly?
I'm using only Java Security code here. I'm not doing anything with HTTP client
anymore.
was (Author: ndipiazza_gmail):
Yeah I've noticed something that is this hard to understand once it "works"
(meaning lets you authenticate and make authenticated http requests to get the
content you need), people shrug off issues with the security because they don't
care.
Can you possibly help me out a little by highlighting some changes to make to
my {{SpnegoAuth}} class to fix the issues? Or is it so far off that I wasted my
time here?
Or could you possibly highlight where in particular libserf does this
correctly?
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577331#comment-16577331
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 9:27 PM:
Hey [~michael-o] thanks for pointing that out. I removed the other example and
am instead going to work on an example here:
https://github.com/nddipiazza/spnego-http-client
Can you look and see if I correctly address the problem?
I am basically stealing this code from this class
https://github.com/AsyncHttpClient/async-http-client/blob/master/client/src/main/java/org/asynchttpclient/spnego/SpnegoEngine.java
. Is this class also affected by this {{GSSContext}} sharing issue?
I did attempt to read the RFC but those things are hard to interpret so I'm not
sure if I fixed what you were referring to.
was (Author: ndipiazza_gmail):
Hey [~michael-o] thanks for pointing that out. I removed the other example and
am instead going to work on an example here:
https://github.com/nddipiazza/spnego-http-client
Can you look and see if I correctly address the problem?
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577165#comment-16577165
]
Michael Osipov edited comment on HTTPCLIENT-1912 at 8/11/18 8:47 PM:
-
Your implementation is incorrect. The {{GSSContext}} must be maintained
stateful and has to be completed. The way you made it makes it inherently
insecure. Please read RFC 7546.
was (Author: michael-o):
Your implementation is incorrect. The {{GSSContext}} must be maintained
stateful and has to be completed. The way you made it makes is inherently
insecure. Please read RFC 7546.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577144#comment-16577144
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 8:27 PM:
The following example shows how you can do preemptive spnego login with HTTP
client that uses a custom entry in the {{login.conf}}. This completely bypasses
the AuthScheme stuff and does all the work of generating the "authorization"
header. So you will notice the example is just a simple minimal http client
with a single header on the httpget request doing all the authentication work.
{code}
... better version below ...
{code}
Might be worth trying to find some way to get this as a supported auth scheme
type, or add this example to the docs.
was (Author: ndipiazza_gmail):
The following example shows how you can do preemptive spnego login with HTTP
client that uses a custom entry in the {{login.conf}}. This completely bypasses
the AuthScheme stuff and does all the work of generating the "authorization"
header. So you will notice the example is just a simple minimal http client
with a single header on the httpget request doing all the authentication work.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import java.net.InetAddress;
import java.security.PrivilegedExceptionAction;
import java.util.Base64;
public class AsyncHttpSpnego {
public static final String SPNEGO_OID = "1.3.6.1.5.5.2";
private static final String KERBEROS_OID = "1.2.840.113554.1.2.2";
public static void main(String[] args) throws Exception {
InetAddress inetAddress = InetAddress.getLocalHost();
String host = inetAddress.getHostName().toUpperCase();
System.setProperty("java.security.krb5.conf", new File(host +
"-krb5.ini").getCanonicalPath());
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
System.setProperty("java.security.auth.login.config", new File(host +
"-login.conf").getCanonicalPath());
LoginContext lc = new LoginContext("anotherentry");
lc.login();
byte[] token = new byte[0];
token = getAuthToken(host, lc, token);
String authorizationHeader = "Negotiate" + " " +
Base64.getEncoder().encodeToString(token);
System.out.println("Next Authorization header: " + authorizationHeader);
CloseableHttpClient closeableHttpClient = HttpClients.createMinimal();
HttpGet httpget = new HttpGet("http://; + host + ":81/nick.txt");
httpget.setHeader("Authorization", authorizationHeader);
CloseableHttpResponse closeableHttpResponse =
closeableHttpClient.execute(httpget);
try {
System.out.println(IOUtils.toString(closeableHttpResponse.getEntity().getContent()));
} finally {
closeableHttpResponse.close();
}
}
private static byte[] getAuthToken(String host, LoginContext lc, byte[]
inToken) throws GSSException, java.security.PrivilegedActionException {
Oid negotiationOid = new Oid(SPNEGO_OID);
GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionAction action = () ->
manager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME, negotiationOid,
GSSCredential.INITIATE_AND_ACCEPT);
boolean tryKerberos = false;
GSSContext gssContext = null;
try {
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext =
manager.createContext(serverName.canonicalize(negotiationOid), negotiationOid,
Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
} catch (GSSException ex) {
if (ex.getMajor() == GSSException.BAD_MECH) {
System.out.println("GSSException BAD_MECH, retry with Kerberos MECH");
tryKerberos = true;
} else {
throw ex;
}
}
if (tryKerberos) {
Oid kerbOid = new Oid(KERBEROS_OID);
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext = manager.createContext(serverName.canonicalize(kerbOid),
kerbOid, Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
}
return gssContext.initSecContext(inToken, 0, inToken.length);
}
}
{code}
Might be worth trying to find some way
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577144#comment-16577144
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 8:27 PM:
The following example shows how you can do preemptive spnego login with HTTP
client that uses a custom entry in the {{login.conf}}. This completely bypasses
the AuthScheme stuff and does all the work of generating the "authorization"
header. So you will notice the example is just a simple minimal http client
with a single header on the httpget request doing all the authentication work.
{code}
... working on a better version below ...
{code}
Might be worth trying to find some way to get this as a supported auth scheme
type, or add this example to the docs.
was (Author: ndipiazza_gmail):
The following example shows how you can do preemptive spnego login with HTTP
client that uses a custom entry in the {{login.conf}}. This completely bypasses
the AuthScheme stuff and does all the work of generating the "authorization"
header. So you will notice the example is just a simple minimal http client
with a single header on the httpget request doing all the authentication work.
{code}
... better version below ...
{code}
Might be worth trying to find some way to get this as a supported auth scheme
type, or add this example to the docs.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577144#comment-16577144
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 11:28 AM:
-
The following example shows how you can do preemptive spnego login with HTTP
client that uses a custom entry in the {{login.conf}}. This completely bypasses
the AuthScheme stuff and does all the work of generating the "authorization"
header. So you will notice the example is just a simple minimal http client
with a single header on the httpget request doing all the authentication work.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import java.net.InetAddress;
import java.security.PrivilegedExceptionAction;
import java.util.Base64;
public class AsyncHttpSpnego {
public static final String SPNEGO_OID = "1.3.6.1.5.5.2";
private static final String KERBEROS_OID = "1.2.840.113554.1.2.2";
public static void main(String[] args) throws Exception {
InetAddress inetAddress = InetAddress.getLocalHost();
String host = inetAddress.getHostName().toUpperCase();
System.setProperty("java.security.krb5.conf", new File(host +
"-krb5.ini").getCanonicalPath());
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
System.setProperty("java.security.auth.login.config", new File(host +
"-login.conf").getCanonicalPath());
LoginContext lc = new LoginContext("anotherentry");
lc.login();
byte[] token = new byte[0];
token = getAuthToken(host, lc, token);
String authorizationHeader = "Negotiate" + " " +
Base64.getEncoder().encodeToString(token);
System.out.println("Next Authorization header: " + authorizationHeader);
CloseableHttpClient closeableHttpClient = HttpClients.createMinimal();
HttpGet httpget = new HttpGet("http://; + host + ":81/nick.txt");
httpget.setHeader("Authorization", authorizationHeader);
CloseableHttpResponse closeableHttpResponse =
closeableHttpClient.execute(httpget);
try {
System.out.println(IOUtils.toString(closeableHttpResponse.getEntity().getContent()));
} finally {
closeableHttpResponse.close();
}
}
private static byte[] getAuthToken(String host, LoginContext lc, byte[]
inToken) throws GSSException, java.security.PrivilegedActionException {
Oid negotiationOid = new Oid(SPNEGO_OID);
GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionAction action = () ->
manager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME, negotiationOid,
GSSCredential.INITIATE_AND_ACCEPT);
boolean tryKerberos = false;
GSSContext gssContext = null;
try {
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext =
manager.createContext(serverName.canonicalize(negotiationOid), negotiationOid,
Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
} catch (GSSException ex) {
if (ex.getMajor() == GSSException.BAD_MECH) {
System.out.println("GSSException BAD_MECH, retry with Kerberos MECH");
tryKerberos = true;
} else {
throw ex;
}
}
if (tryKerberos) {
Oid kerbOid = new Oid(KERBEROS_OID);
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext = manager.createContext(serverName.canonicalize(kerbOid),
kerbOid, Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
}
return gssContext.initSecContext(inToken, 0, inToken.length);
}
}
{code}
Might be worth trying to find some way to get this as a supported auth scheme
type, or add this example to the docs.
was (Author: ndipiazza_gmail):
The following example shows how you can do preemptive spnego login that uses a
custom entry in the {{login.conf}}. This completely bypasses the AuthScheme
stuff and does all the work of generating the "authorization" header.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577144#comment-16577144
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 11:25 AM:
-
The following example shows how you can do preemptive spnego login that uses a
custom entry in the {{login.conf}}. This completely bypasses the AuthScheme
stuff and does all the work of generating the "authorization" header.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import java.net.InetAddress;
import java.security.PrivilegedExceptionAction;
import java.util.Base64;
public class AsyncHttpSpnego {
public static final String SPNEGO_OID = "1.3.6.1.5.5.2";
private static final String KERBEROS_OID = "1.2.840.113554.1.2.2";
public static void main(String[] args) throws Exception {
InetAddress inetAddress = InetAddress.getLocalHost();
String host = inetAddress.getHostName().toUpperCase();
System.setProperty("java.security.krb5.conf", new File(host +
"-krb5.ini").getCanonicalPath());
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
System.setProperty("java.security.auth.login.config", new File(host +
"-login.conf").getCanonicalPath());
LoginContext lc = new LoginContext("anotherentry");
lc.login();
byte[] token = new byte[0];
token = getAuthToken(host, lc, token);
String authorizationHeader = "Negotiate" + " " +
Base64.getEncoder().encodeToString(token);
System.out.println("Next Authorization header: " + authorizationHeader);
CloseableHttpClient closeableHttpClient = HttpClients.createMinimal();
HttpGet httpget = new HttpGet("http://; + host + ":81/nick.txt");
httpget.setHeader("Authorization", authorizationHeader);
CloseableHttpResponse closeableHttpResponse =
closeableHttpClient.execute(httpget);
try {
System.out.println(IOUtils.toString(closeableHttpResponse.getEntity().getContent()));
} finally {
closeableHttpResponse.close();
}
}
private static byte[] getAuthToken(String host, LoginContext lc, byte[]
inToken) throws GSSException, java.security.PrivilegedActionException {
Oid negotiationOid = new Oid(SPNEGO_OID);
GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionAction action = () ->
manager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME, negotiationOid,
GSSCredential.INITIATE_AND_ACCEPT);
boolean tryKerberos = false;
GSSContext gssContext = null;
try {
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext =
manager.createContext(serverName.canonicalize(negotiationOid), negotiationOid,
Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
} catch (GSSException ex) {
if (ex.getMajor() == GSSException.BAD_MECH) {
System.out.println("GSSException BAD_MECH, retry with Kerberos MECH");
tryKerberos = true;
} else {
throw ex;
}
}
if (tryKerberos) {
Oid kerbOid = new Oid(KERBEROS_OID);
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext = manager.createContext(serverName.canonicalize(kerbOid),
kerbOid, Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
}
return gssContext.initSecContext(inToken, 0, inToken.length);
}
}
{code}
Might be worth trying to find some way to get this as a supported auth scheme
type, or add this example to the docs.
was (Author: ndipiazza_gmail):
The following example shows how you can do preemptive spnego login that uses a
custom entry in the {{login.conf}}. This completely bypasses the AuthScheme
stuff and does all the work of generating the "authorization" header.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577144#comment-16577144
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 11:22 AM:
-
The following example shows how you can do preemptive spnego login that uses a
custom entry in the {{login.conf}}. This completely bypasses the AuthScheme
stuff and does all the work of generating the "authorization" header.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import java.net.InetAddress;
import java.security.PrivilegedExceptionAction;
import java.util.Base64;
public class AsyncHttpSpnego {
public static final String SPNEGO_OID = "1.3.6.1.5.5.2";
private static final String KERBEROS_OID = "1.2.840.113554.1.2.2";
public static void main(String[] args) throws Exception {
InetAddress inetAddress = InetAddress.getLocalHost();
String host = inetAddress.getHostName().toUpperCase();
System.setProperty("java.security.krb5.conf", new File(host +
"-krb5.ini").getCanonicalPath());
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
System.setProperty("java.security.auth.login.config", new File(host +
"-login.conf").getCanonicalPath());
LoginContext lc = new LoginContext("anotherentry");
lc.login();
byte[] token = new byte[0];
token = getAuthToken(host, lc, token);
String authorizationHeader = "Negotiate" + " " +
Base64.getEncoder().encodeToString(token);
System.out.println("Next Authorization header: " + authorizationHeader);
CloseableHttpClient closeableHttpClient = HttpClients.createMinimal();
HttpGet httpget = new HttpGet("http://; + host + ":81/nick.txt");
httpget.setHeader("Authorization", authorizationHeader);
CloseableHttpResponse closeableHttpResponse =
closeableHttpClient.execute(httpget);
try {
System.out.println(IOUtils.toString(closeableHttpResponse.getEntity().getContent()));
} finally {
closeableHttpResponse.close();
}
}
private static byte[] getAuthToken(String host, LoginContext lc, byte[]
inToken) throws GSSException, java.security.PrivilegedActionException {
Oid negotiationOid = new Oid(SPNEGO_OID);
GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionAction action = () ->
manager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME, negotiationOid,
GSSCredential.INITIATE_AND_ACCEPT);
boolean tryKerberos = false;
GSSContext gssContext = null;
try {
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext =
manager.createContext(serverName.canonicalize(negotiationOid), negotiationOid,
Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
} catch (GSSException ex) {
if (ex.getMajor() == GSSException.BAD_MECH) {
System.out.println("GSSException BAD_MECH, retry with Kerberos MECH");
tryKerberos = true;
} else {
throw ex;
}
}
if (tryKerberos) {
Oid kerbOid = new Oid(KERBEROS_OID);
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext = manager.createContext(serverName.canonicalize(kerbOid),
kerbOid, Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
}
return gssContext.initSecContext(inToken, 0, inToken.length);
}
}
{code}
was (Author: ndipiazza_gmail):
The following example shows how you can do preemptive spnego login. This
completely bypasses the AuthScheme stuff and does all the work of generating
the "authorization" header.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577144#comment-16577144
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/11/18 11:19 AM:
-
The following example shows how you can do preemptive spnego login. This
completely bypasses the AuthScheme stuff and does all the work of generating
the "authorization" header.
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import java.net.InetAddress;
import java.security.PrivilegedExceptionAction;
import java.util.Base64;
public class AsyncHttpSpnego {
public static final String SPNEGO_OID = "1.3.6.1.5.5.2";
private static final String KERBEROS_OID = "1.2.840.113554.1.2.2";
public static void main(String[] args) throws Exception {
InetAddress inetAddress = InetAddress.getLocalHost();
String host = inetAddress.getHostName().toUpperCase();
System.setProperty("java.security.krb5.conf", new File(host +
"-krb5.ini").getCanonicalPath());
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
System.setProperty("java.security.auth.login.config", new File(host +
"-login.conf").getCanonicalPath());
LoginContext lc = new LoginContext("anotherentry");
lc.login();
byte[] token = new byte[0];
token = getAuthToken(host, lc, token);
String authorizationHeader = "Negotiate" + " " +
Base64.getEncoder().encodeToString(token);
System.out.println("Next Authorization header: " + authorizationHeader);
CloseableHttpClient closeableHttpClient = HttpClients.createMinimal();
HttpGet httpget = new HttpGet("http://; + host + ":81/nick.txt");
httpget.setHeader("Authorization", authorizationHeader);
CloseableHttpResponse closeableHttpResponse =
closeableHttpClient.execute(httpget);
try {
System.out.println(IOUtils.toString(closeableHttpResponse.getEntity().getContent()));
} finally {
closeableHttpResponse.close();
}
}
private static byte[] getAuthToken(String host, LoginContext lc, byte[]
inToken) throws GSSException, java.security.PrivilegedActionException {
Oid negotiationOid = new Oid(SPNEGO_OID);
GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionAction action = () ->
manager.createCredential(null,
GSSCredential.INDEFINITE_LIFETIME, negotiationOid,
GSSCredential.INITIATE_AND_ACCEPT);
boolean tryKerberos = false;
GSSContext gssContext = null;
try {
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext =
manager.createContext(serverName.canonicalize(negotiationOid), negotiationOid,
Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
} catch (GSSException ex) {
if (ex.getMajor() == GSSException.BAD_MECH) {
System.out.println("GSSException BAD_MECH, retry with Kerberos MECH");
tryKerberos = true;
} else {
throw ex;
}
}
if (tryKerberos) {
Oid kerbOid = new Oid(KERBEROS_OID);
GSSName serverName = manager.createName("HTTP@" + host,
GSSName.NT_HOSTBASED_SERVICE);
gssContext = manager.createContext(serverName.canonicalize(kerbOid),
kerbOid, Subject.doAs(lc.getSubject(), action),
GSSContext.DEFAULT_LIFETIME);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
}
return gssContext.initSecContext(inToken, 0, inToken.length);
}
}
{code}
was (Author: ndipiazza_gmail):
The following example shows how you can do preemptive spnego login. This
completely bypasses the AuthScheme stuff and does all the work
{code}
import org.apache.commons.io.IOUtils;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSCredential;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import java.io.File;
import java.net.InetAddress;
import java.security.PrivilegedExceptionAction;
import java.util.Base64;
public class
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576545#comment-16576545
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/10/18 4:37 PM:
Hey [~michael-o] I had been working on a different project for a while there
now I'm back to this.
So you sent me an example of TomcatAuthenticator code. Is that because it's a
similar thing doing what I'm trying to do?
OK let's say I've created the login context and have logged in.
Can you give me some high level code for
{blockquote}
wrap your HTTP call within a PrivilegedExceptionAction and call Subject#doAs()
{blockquote}
That part was greek to me.
was (Author: ndipiazza_gmail):
Hey [~michael-o] I had been working on a different project for a while there
now I'm back to this.
So you sent me an example of TomcatAuthenticator code. Is that because it's a
similar thing doing what I'm trying to do?
OK let's say I've created the login context and have logged in.
Can you give me some high level code for
{code}
wrap your HTTP call within a PrivilegedExceptionAction and call Subject#doAs()
{code}
That part was greek to me.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576545#comment-16576545
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/10/18 4:37 PM:
Hey [~michael-o] I had been working on a different project for a while there
now I'm back to this.
So you sent me an example of TomcatAuthenticator code. Is that because it's a
similar thing doing what I'm trying to do?
OK let's say I've created the login context and have logged in.
Can you give me some high level code for
{code}
wrap your HTTP call within a PrivilegedExceptionAction and call Subject#doAs()
{code}
That part was greek to me.
was (Author: ndipiazza_gmail):
Hey [~michael-o] I had been working on a different project for a while there
now I'm back to this.
So you sent me an example of TomcatAuthenticator code. Is that because it's a
similar thing doing what I'm trying to do?
OK let's say I've created the login context and have logged in.
Can you give me some high level code for {{wrap your HTTP call within a
PrivilegedExceptionAction and call Subject#doAs(}}? That was greek to me.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576545#comment-16576545
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 8/10/18 4:37 PM:
Hey [~michael-o] I had been working on a different project for a while there
now I'm back to this.
So you sent me an example of TomcatAuthenticator code. Is that because it's a
similar thing doing what I'm trying to do?
OK let's say I've created the login context and have logged in.
Can you give me some high level code for
{quote}wrap your HTTP call within a PrivilegedExceptionAction and call
Subject#doAs(){quote}
That part was greek to me.
was (Author: ndipiazza_gmail):
Hey [~michael-o] I had been working on a different project for a while there
now I'm back to this.
So you sent me an example of TomcatAuthenticator code. Is that because it's a
similar thing doing what I'm trying to do?
OK let's say I've created the login context and have logged in.
Can you give me some high level code for
{blockquote}
wrap your HTTP call within a PrivilegedExceptionAction and call Subject#doAs()
{blockquote}
That part was greek to me.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427841#comment-16427841
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 4/6/18 2:17 AM:
---
Hey [~michael-o]
If I could figure out how to tell HttpClient to use a certain Entry name within
the login.conf, that would help me a lot.
See [this
link|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/AcnOnly.html#ClientLC]
from the JAAS documentation that shows that the LoginContext takes an entry
name.
How does the AuthSchemes.SPNEGO pick the entry name it uses?
in other words
login.conf:
{code}
KrbLogin {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/home/ndipiazza/kerberos.keytab"
useTicketCache=true
principal="HTTP/kerberos.some.domain@SOME.DOMAIN"
debug=true;
};
KrbLogin2 {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/home/ndipiazza/kerberos.keytab"
useTicketCache=true
principal="HTTP/kerberos.some.domain@SOME.DOMAIN"
debug=true;
};
{code}
It seems like Windows uses KrbLogin. How can I get it to use KrbLogin2?
Looks to me like it just uses the default. Which I don't quite understand.
I think similar work was done on the Hadoop project
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/client/KerberosAuthenticator.java
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/KerberosUtil.java
I don't quite fully understand how all of this works yet but, i was wondering
if you could give me a hand in getting all of the source checked out I'll need
to get this done? thanks.
was (Author: ndipiazza_gmail):
Hey [~michael-o]
If I could figure out how to tell HttpClient to use a certain Entry name within
the login.conf, that would help me a lot.
See [this
link|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/AcnOnly.html#ClientLC]
from the JAAS documentation that shows that the LoginContext takes an entry
name.
How does the AuthSchemes.SPNEGO pick the entry name it uses?
in other words
login.conf:
{code}
KrbLogin {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/home/ndipiazza/kerberos.keytab"
useTicketCache=true
principal="HTTP/kerberos.some.domain@SOME.DOMAIN"
debug=true;
};
KrbLogin2 {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/home/ndipiazza/kerberos.keytab"
useTicketCache=true
principal="HTTP/kerberos.some.domain@SOME.DOMAIN"
debug=true;
};
{code}
It seems like Windows uses KrbLogin. How can I get it to use KrbLogin2?
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427841#comment-16427841
]
Nicholas DiPiazza edited comment on HTTPCLIENT-1912 at 4/6/18 1:36 AM:
---
Hey [~michael-o]
If I could figure out how to tell HttpClient to use a certain Entry name within
the login.conf, that would help me a lot.
See [this
link|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/AcnOnly.html#ClientLC]
from the JAAS documentation that shows that the LoginContext takes an entry
name.
How does the AuthSchemes.SPNEGO pick the entry name it uses?
in other words
login.conf:
{code}
KrbLogin {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/home/ndipiazza/kerberos.keytab"
useTicketCache=true
principal="HTTP/kerberos.some.domain@SOME.DOMAIN"
debug=true;
};
KrbLogin2 {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/home/ndipiazza/kerberos.keytab"
useTicketCache=true
principal="HTTP/kerberos.some.domain@SOME.DOMAIN"
debug=true;
};
{code}
It seems like Windows uses KrbLogin. How can I get it to use KrbLogin2?
was (Author: ndipiazza_gmail):
Hey [~michael-o]
If I could figure out how to tell HttpClient to use a certain Entry name within
the login.conf, that would help me a lot.
See [this
link|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/AcnOnly.html#ClientLC]
from the JAAS documentation that shows that the LoginContext takes an entry
name.
How does the AuthSchemes.SPNEGO pick the entry name it uses?
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
> Labels: volunteers-wanted
> Fix For: Stuck
>
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426196#comment-16426196
]
Michael Osipov edited comment on HTTPCLIENT-1912 at 4/4/18 9:27 PM:
Correct, it has been designed from the ground up as a single app per VM which
isn't true for webapps. Same as this crap: {{ProxySelector}}. VM wide
configuration.
If you have a smart idea, I am all ears. But the {{krb.conf}} is system-global,
there is no need to have multiple ones.
was (Author: michael-o):
Correct, it has been designed from the ground up as a single app per VM which
isn't true for webapps. Same as this crap: {{ProxySelector}}. VM wide
configuration.
If you have a smart idea, I al all ears.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1912) AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as parameters instead of system properties
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426196#comment-16426196
]
Michael Osipov edited comment on HTTPCLIENT-1912 at 4/4/18 9:27 PM:
Correct, it has been designed from the ground up as a single app per VM which
isn't true for webapps. Same as this crap: {{ProxySelector}}. VM wide
configuration.
If you have a smart idea, I al all ears.
was (Author: michael-o):
Correct, it has been designed from the ground up as a single app per VM which
isn't true for webapps. Same as this crap: {{ProxySelector}}. VM wide
configuration.
> AuthSchemes.SPNEGO should be able to specify login conf and krb5 conf as
> parameters instead of system properties
>
>
> Key: HTTPCLIENT-1912
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1912
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Nicholas DiPiazza
>Priority: Major
>
> in order to use spenego
> see
> [example|https://github.com/jumarko/kerberos-auth-example/blob/master/src/main/java/net/curiousprogrammer/auth/kerberos/example/KerberosAuthExample.java]
> you need to specify system properties to specify a custom krb5.conf or
> login.conf location.
> It would be very useful if these could be given as parameters somehow instead
> of system properties, because in our cloud apps use case, sharing these as
> system properties at the jvm level is causing conflicts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
