Re: [JSch-users] Issue with GSSAPI and authorization for multiple principals

[Borislav S. <jsc...@me...>]

Hello Vadim

The code is functional of course all references to username are no longer
needed. In fact if you only call createContext with null as the credential
the functionality is the same. I believe this will take care of the
current issue.

If you recall I sent you a question about how I can use an exsiting
context/credential to initiate a connection. I was confused and thought I
needed to create a valid credential beforehand. Instead this is taken care
of inside jsch based on the login config file. It is easy from a
developer's standpoint.

I think a valid approach to mimic openssh would be to remove the
createCredetial part from jsch alltogether and add a method to Jsch like
AddIdentity(GSSCredential crd) and only consider  UserAuthGSSAPIWithMIC if
crd is defined. And use crd inside GSSContextKrb5. This way the credential
needs to be created before Jsch() and the credential properties(lifetime,
etc.) can be manipulated as well as how the credentials are established
will  be outside the scope of Jsch itself (much like openssh).

I want to say it is OK to leave it as it is and allow users to login but
my mind is split. If compatibility with openssh is the goal then initial
authentication should occur outside of Jsch.

Of course I may be missing something. Thanks.

Borislav

> Hi all,
>
> what do you think abou following possibility?
>
> GSSCredential crd=mgr.createCredential(null,
>                                        GSSCredential.DEFAULT_LIFETIME,
>                                        krb5,
>                                        GSSCredential.INITIATE_ONLY);
>
> String cname=host;
> try{
>         cname=InetAddress.getByName(cname).getCanonicalHostName();
> }catch(UnknownHostException e){
> }
> GSSName _host=mgr.createName("host/"+cname, principalName);
>
> context=mgr.createContext(_host,
>                           krb5,
>                           crd,
>                           GSSContext.DEFAULT_LIFETIME);
>
> Please notice null as first argument in createCredential.
>
> In such case, if it finds *any* TGT in cache, it will try to use it.
> Result of course depends on what you have in .k5login. Otherwise it will
> try to use callbacks to ask user about kerberos principal and password.
>
> Nevertheless, gentlemen, main question remains. That's do you find it
> over all meaningful to provide user possibility to enter
> principal/password, or you better mimic openssh, e.g. try to use
> available TGT only and do not provide user a possibility to login in
> realm at all?
>
> best regards, vadim tarassov
>
> On Tue, 2007-02-27 at 10:33 +0900, Atsuhiko Yamanaka wrote:
>> Hi,
>>
>>    +-From: "Borislav Stoichkov" <jsc...@me...> --
>>    |_Date: Mon, 26 Feb 2007 08:10:00 -0800 (PST) ____________
>>    |
>>    |My opinion is that there should be no conection between the
>> destination
>>    |username and the credentials used as principals can be mapped to
>> user id's
>>    |through other external mechanisms. Hope I am making sense. Thanks.
>>
>> I'm referring to the OpenSSH code and it seems that the username is not
>> referred in creating context by using GSSAPI.
>> vadim, if there is no problem for you, I'll stop to invoke
>>   GSSManager#createCredential .
>> How do you think?
>>
>>
>> Sincerely,
>> --
>> Atsuhiko Yamanaka
>> JCraft,Inc.
>> 1-14-20 HONCHO AOBA-KU,
>> SENDAI, MIYAGI 980-0014 Japan.
>> Tel +81-22-723-2150
>>     +1-415-578-3454
>> Fax +81-22-224-8773
>> Skype callto://jcraft/
>>
>>
>