headers
Graham Shaw | 23 Apr 07:02

Suppresion of password prompt

A question.

I'm trying to find a way to prevent the Shishi library from prompting for
a password.  Specifically:

1. When obtaining an initial TGT I want to supply a password to be tried,
and if that doesn't work I want it to give up.
2. When obtaining a service ticket I want it to give up if there is no
suitable TGT available.

I have a workaround but it involves modifying the library.  (Either that
or driving it through stdin/stdout, which apart from being fragile would
be awkward to implement on the platform I'm developing for.)

Is there an approved method for achieving the above?

With thanks,

--

-- 
Graham Shaw (http://www.riscpkg.org/~gdshaw/)
The RISC OS Packaging Project (http://www.riscpkg.org/)
The RISC OS Toolkit (http://rtk.riscos.org.uk/)
Permalink | Reply |
headers
Simon Josefsson | 23 Apr 13:26
Favicon
Gravatar

Re: Suppresion of password prompt

Graham Shaw <gdshaw <at> riscpkg.org> writes:

> A question.
>
> I'm trying to find a way to prevent the Shishi library from prompting for
> a password.  Specifically:
>
> 1. When obtaining an initial TGT I want to supply a password to be tried,
> and if that doesn't work I want it to give up.
> 2. When obtaining a service ticket I want it to give up if there is no
> suitable TGT available.
>
> I have a workaround but it involves modifying the library.  (Either that
> or driving it through stdin/stdout, which apart from being fragile would
> be awkward to implement on the platform I'm developing for.)
>
> Is there an approved method for achieving the above?

Hi.  Thanks for your interest.  Which API are you using?  I'm assuming
you are using the shishi_tkts_* interface to get tickets, which is the
recommended high-level interface.

Regarding 1), you can supply a password to be used by using a
Shishi_tkts_hint structure and set the 'passwd' field in it.  It will be
used when getting a TGT when decrypting the AS-REP.  Something like:

  Shishi_tkt *tkt;
  Shishi_tkts_hint hint;
  int rc;
(Continue reading)

Permalink | Reply |
headers
Graham Shaw | 23 Apr 21:02

Re: Suppresion of password prompt

On 23 Apr, Simon Josefsson <simon <at> josefsson.org> wrote:
> Graham Shaw <gdshaw <at> riscpkg.org> writes:

> > 1. When obtaining an initial TGT I want to supply a password to be
> > tried, and if that doesn't work I want it to give up.
> > 2. When obtaining a service ticket I want it to give up if there is no
> > suitable TGT available.

> Hi.  Thanks for your interest.  Which API are you using?  I'm assuming
> you are using the shishi_tkts_* interface to get tickets, which is the
> recommended high-level interface.

Correct.

> I see now that if the server requires pre-authentication (using a
> password) I see now that the code will not use the provided password,
> but instead will prompt for a new password.  I have fixed this, see:

> http://git.savannah.gnu.org/gitweb/?p=shishi.git;a=commitdiff;h=bdf277a51182c49b13b61ac6f57b8111dcbf94a5

Thanks - that appears to work perfectly.

> Regarding 2), use shishi_tkts_find() instead which will only search
> among your existing tickets.  The shishi_tkts_get* APIs will try to get
> a ticket if it doesn't exist -- it calls shishi_tkts_find() first.

That isn't quite the functionality I'm looking for:
- if the client doesn't already have a service ticket then I do want it to
request one from the KDC using the TGT, however
- if the client doesn't have a TGT then I don't want it to prompt for a
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 24 Apr 11:55
Favicon
Gravatar

Re: Suppresion of password prompt

Graham Shaw <gdshaw <at> riscpkg.org> writes:

>> I see now that if the server requires pre-authentication (using a
>> password) I see now that the code will not use the provided password,
>> but instead will prompt for a new password.  I have fixed this, see:
>
>> http://git.savannah.gnu.org/gitweb/?p=shishi.git;a=commitdiff;h=bdf277a51182c49b13b61ac6f57b8111dcbf94a5
>
> Thanks - that appears to work perfectly.

Ok.

>> Regarding 2), use shishi_tkts_find() instead which will only search
>> among your existing tickets.  The shishi_tkts_get* APIs will try to get
>> a ticket if it doesn't exist -- it calls shishi_tkts_find() first.
>
> That isn't quite the functionality I'm looking for:
> - if the client doesn't already have a service ticket then I do want it to
> request one from the KDC using the TGT, however
> - if the client doesn't have a TGT then I don't want it to prompt for a
> password.
>
> (The former is OK because it's an entirely non-interactive process,
> whereas the latter takes input from the user so is something I need to
> avoid.)

I can think of two easy solutions:

1) Add a new Shishi_tkts_hintflags flag such as
SHISHI_TKTSHINTFLAGS_NON_INTERACTIVE which inhibits all password
(Continue reading)

Permalink | Reply |
headers
Graham Shaw | 25 Apr 05:26

Re: Suppresion of password prompt

In article <87ej8v60gg.fsf <at> mocca.josefsson.org>,
   Simon Josefsson <simon <at> josefsson.org> wrote:
> Graham Shaw <gdshaw <at> riscpkg.org> writes:

> I can think of two easy solutions:

> 1) Add a new Shishi_tkts_hintflags flag such as
> SHISHI_TKTSHINTFLAGS_NON_INTERACTIVE which inhibits all password
> queries.  We probably need a new error code to signal that the command
> failed for this reason.

> 2) Add a callback interface for dealing with password queries.  This
> allows you to get a callback when a password is needed.  The callback
> could fail (which presumably it would in a non-interactive situation).
> We probably need to add the same error code here as well.

> Can you think of something else that would solve your problem better?
> Which do you prefer?  I could implement both, they both seem useful.

Either would fully solve my current problem, so from a personal POV I
don't have any preference.

The first would be marginally easier to use, but I think the difference is
small.  You could narrow the gap by implementing the non-interactive
version of the callback as part of the library, so that the user doesn't
have to - that way it would be one line of code either way.  (If you did
that then I don't think there would be any advantage in having the flag
too, because it would be so easy to achieve the same effect with the
callback.)
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 19 Jun 17:12
Favicon
Gravatar

Re: Suppresion of password prompt

Hello Graham, sorry for the slow response.

Graham Shaw <gdshaw <at> riscpkg.org> writes:

> In article <87ej8v60gg.fsf <at> mocca.josefsson.org>,
>    Simon Josefsson <simon <at> josefsson.org> wrote:
>> Graham Shaw <gdshaw <at> riscpkg.org> writes:
>
>> I can think of two easy solutions:
>
>> 1) Add a new Shishi_tkts_hintflags flag such as
>> SHISHI_TKTSHINTFLAGS_NON_INTERACTIVE which inhibits all password
>> queries.  We probably need a new error code to signal that the command
>> failed for this reason.
>
>> 2) Add a callback interface for dealing with password queries.  This
>> allows you to get a callback when a password is needed.  The callback
>> could fail (which presumably it would in a non-interactive situation).
>> We probably need to add the same error code here as well.
>
>> Can you think of something else that would solve your problem better?
>> Which do you prefer?  I could implement both, they both seem useful.
>
> Either would fully solve my current problem, so from a personal POV I
> don't have any preference.
>
> The first would be marginally easier to use, but I think the difference is
> small.  You could narrow the gap by implementing the non-interactive
> version of the callback as part of the library, so that the user doesn't
> have to - that way it would be one line of code either way.  (If you did
(Continue reading)

Permalink | Reply |

Gmane