search

ymartin59 / java-kerberos-sfudemo

Java 8 Kerberos MS-SFU Demonstration Code
Apache License 2.0
13 stars 8 forks source link

Several issues with the demo code #1

Closed michael-o closed 8 years ago

michael-o commented 8 years ago

Hi Yves,

your code has some shortcomings:

  1. main: HTTP/webservice-host.domain.ltd is not a valid SPN GSS-API expects. It expects a mech-neutral format service@host which will be converted to a mech-specific name with canonicalize. This will also work cross-realm.

  2. Rather use host than HTTP because a host ist always available with a machine principal.

  3. main: Rather use for targetUserName user@DOMAIN.TLD to make it consistent.

  4. generateToken does not indicate that the context is complete nor does it test that. It should clearly say that it is for demo purposes. Not doing so makes the entire stuff insecure.

  5. startAsClient: don't request confidentiality if you do not intend to wrap the exchanged data.

  6. startAsClient: don't request mutual authentication if you don't validate the response token from the server

  7. Line 198: That should read SPN and not SVN
ymartin59 commented 8 years ago

Hello Michael,

Thanks for your feedback. You're exactly right, it is for demo purposes... I will add comments to detail code behaviour. Probably I will then have some questions for you.

michael-o commented 8 years ago

Waiting for the changes to review. Ask me whenever you are ready.

ymartin59 commented 8 years ago

Hello Michael, I have addressed most of your remarks. May you confirm that context.requestCredDeleg(true) is the only required called to allow called service to delegate to a next hop ? Regards Yves Martin

michael-o commented 8 years ago

That is correct. The KDC will check whether the target service is allowed to delegate and will embed a TGT into the service ticket.

michael-o commented 8 years ago

I am looking through the code now.

michael-o commented 8 years ago

Here are the open points:

  1. GSSName servicePrincipal = manager.createName(target, KRB5_PRINCIPAL_OID);: not correct. Pass a mech-agnostic service principal service@host with NT_HOSTBASED_SERVICE and canonicalize that with the KRB5_OID.
  2. #generateToken: Calling getSrcName and getTargName here is invalid. Read the Javadoc when you can call it.
  3. targetSPN = "HTTP/webservice-host.domain.ltd" not correct, see 1.

This should be it for now. I will recheck after another commit.

ymartin59 commented 8 years ago

@michael-o About context.requestCredDeleg(true), you wrote "The KDC will check whether the target service is allowed to delegate and will embed a TGT into the service ticket". According to my understanding, embedding TGT is only the Kerberos-5 way to do delegation.

To grant TGT confidentiality, MS-SFU and kerberos constrained delegation specified that a service requests KDC with the TGS it received from the user to query another service TGS on behalf of this user. Please refer to https://technet.microsoft.com/en-us/library/jj553400.aspx and https://msdn.microsoft.com/en-us/library/cc246080.aspx for details.

michael-o commented 8 years ago

@ymartin59 Is that a question or a conclusion?

ymartin59 commented 8 years ago

@michael-o I would say "a conclusion" based on my reading of SFU/kerberos constrained delegation documents I refer. So there is no longer "embedded TGT" in service ticket when authenticating with kerberos constrained delegation.

michael-o commented 8 years ago

That is true for requestCredDeleg. Therefore, you could even remove it since you want S4U only. I read the specs again and it always talks about S4U2Proxy along with S4U2Self but never about S4U2Proxy only. See this image: Use Kerberos only. I do not understand how this is supposed to work then.

ymartin59 commented 8 years ago

About hostname canonicalization, I understand your point as I had to create a patch in libneon to canonicalize hostname on Windows where SSPI does not handle the process, whereas libgss does on Linux. I had to read Firefox source code to understand why Subversion client does not authenticate with SPNEGO properly with my WebDAV DNS alias. By the way, I consider it is not in this demonstration code scope to include hostname canonicalization. Probably I will address this point later in another demo to send a high-level request with HttpClient or CXF.

michael-o commented 8 years ago

Hostname canonicalization is a client problem, not a library one. I have raised this question on the MIT Kerberos Mailing List several months ago, Tom Yu agreed that canon is not appropriate these days by MIT Kerberos, especially in your DNS alias case. It is a relic from past days. You do not need it uf your setup is right. It is required only in very special cases like multihomed services which cannot run under one service account. So SSPI is doing the right thing. As regarding libneon, I was never fond of this one. I have reported several GSS-API-related issues to the author and offered my help. Nothing was fixed. Luckily, this was replaced with libserf in Subversion 1.8 where devs very cooperative. I have tested and approved the implemenation on Unix.

ymartin59 commented 8 years ago

I agree. But I am still looking for Subversion Windows binaries that supports SPNEGO authentication with hostname canonicalization... If you have tips about one, I am interested.

michael-o commented 8 years ago

I once had a talk with Ivan Zhakov about that and we agreed to drop that for various reasons. You could probably share your DNS setup and I would try to give you an advise on that.

ymartin59 commented 8 years ago

When my setup is really simple. My server FQDN is "svn-prod01.mydomain.ltd" and I have defined a short DNS alias "svn.mydomain.ltd" for user facing access. The latest TortoiseSVN version working properly was 1.6.17. Since then it may sometime work or not. On Linux, SPNEGO authentication has always worked, as far as serf is compiled with GSS-API support.​ Both SPN "HTTP/svn-prod01.mydomain.ltd" and "HTTP/svn.mydomain.ltd" are defined for the service account configured in mod_auth_kerb.

michael-o commented 8 years ago

first of all, I would recommend to setup rdns = false in your krb5.conf to have the same behavior on Windows. As it seems, both SPNs are properly set and associated with the service account. I see no reason why it shouldn't work with the CNAME. I have never used mod_auth_kerb because it is ancient and not maintained. I use michael-o/mod_spnego or modauthgssapi/mod_auth_gssapi if you prefer.

Jacc0 commented 4 years ago

That is true for requestCredDeleg. Therefore, you could even remove it since you want S4U only. I read the specs again and it always talks about S4U2Proxy along with S4U2Self but never about S4U2Proxy only. See this image: Use Kerberos only. I do not understand how this is supposed to work then.

Did you figure out how S4U2Proxy would work without S4U2Self? I'm trying to solve that same issue.