Menu
▾
▴
perl-ldap-dev
|
From: Norbert K. <nor...@da...> - 2002-05-07 11:34:41
Attachments:
external-authzid.patch.txt
|
Hi, RFC2222 says that in the EXTERNAL mechanism "The client sends an initial=20 response with the authorization identity." The attached patch does this. An = authorization identity can be set with the 'authname' callback. --=20 Dipl.-Inform. Norbert Klasen DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
|
From: Graham B. <gb...@po...> - 2002-05-07 12:39:49
|
On Tue, May 07, 2002 at 11:36:04AM +0200, Norbert Klasen wrote:
> Hi,
> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial
> response with the authorization identity." The attached patch does this. An
> authorization identity can be set with the 'authname' callback.
Have you tried this, as it does not look right to me, But Chris could
confirm as he wrote the original. You have changed this from sending
the auth as a response to sending it with the initial request.
The reason it was using user, was for compatability with previous SASL
implementation.
Also, it needs to work the same as the Authen::SASL::Cyrus package
(I have CC'd the author), so if someone can confirm how that works,
we can make it match.
Graham.
> --- /archiv/cvs/perl-ldap/sasl/lib/Authen/SASL/Perl/EXTERNAL.pm Thu Jan 24 13:04:16 2002
> +++ EXTERNAL.pm Tue May 7 11:30:49 2002
> @@ -24,12 +24,16 @@
> sub mechanism { 'EXTERNAL' }
>
> sub client_start {
> - ''
> -}
> + my $self = shift;
>
> -sub client_step {
> - shift->_call('user');
> + my $v = $self->_call('authname');
> + defined($v) ? $v : ''
> }
> +
> +#sub client_step {
> +# shift->_call('user');
> +# ''
> +#}
>
> 1;
>
|
|
From: Chris R. <chr...@me...> - 2002-05-07 14:02:02
|
Graham Barr <gb...@po...> wrote: > On Tue, May 07, 2002 at 11:36:04AM +0200, Norbert Klasen wrote: >> Hi, >> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial >> response with the authorization identity." The attached patch does this. >> An authorization identity can be set with the 'authname' callback. > > Have you tried this, as it does not look right to me, But Chris could > confirm as he wrote the original. You have changed this from sending > the auth as a response to sending it with the initial request. > > The reason it was using user, was for compatability with previous SASL > implementation. Yup, that's the exact reason I did the original version that way. I had one report that it worked correctly... Cheers, Chris |
|
From: Norbert K. <nor...@da...> - 2002-05-08 15:32:21
|
--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote:
> The reason it was using user, was for compatability with previous SASL
> implementation.
How am I supposed to call Authen::SASL->new and Net::LDAP->bind if I don't=20
want to do proxy auth (ie. not specify an authorization identity with the=20
user callback)?
I'm asking this because in Net/LDAP.pm line 242 "user" defaults to
'dn: <DN>', where <DN> is the first parameter to NET::LDAP::bind():
# Tell the SASL object our user identifier
$sasl->callback( user =3D> "dn: $stash{name}")
unless $sasl->callback('user');
So without an explicit "user" callback, perl-ldap will emit the following=20
bind request:
30 1c 02 01 01 60 17 02 01 03 04 00 a3 10 04 08 0....`..........
45 58 54 45 52 4e 41 4c 04 04 64 6e 3a 20 EXTERNAL..dn:
Similar for PLAIN:
30 2a 02 01 01 60 25 02 01 03 04 00 a3 1e 04 05 0*...`%.........
50 4c 41 49 4e 04 15 64 6e 3a 20 00 63 6e 3d 61 PLAIN..dn: .cn=3Da
75 74 68 63 32 00 73 65 63 72 65 74 uthc2.secret
I think the default callback for user should only be set, if $stash{name}=20
actually contains a value:
# Tell the SASL object our user identifier
$sasl->callback( user =3D> "dn: $stash{name}")
unless $sasl->callback('user') || !$stash{name}
This would allow
my $sasl =3D Authen::SASL->new( mechanism =3D> 'EXTERNAL' );
and
$mesg =3D $ldap->bind( '', sasl =3D> $sasl );
or
$mesg =3D $ldap->bind( $proxydn, sasl =3D> $sasl );
BTW how is a server to respond, if it receives different authCids in the=20
name and credentials component of a bind request? With the following code,=20
perl-ldap will emit such a request.
my $sasl =3D Authen::SASL->new(
mechanism =3D> 'PLAIN',
callback =3D> {
pass =3D> 'secret',
user =3D> 'cn=3Dauthz',
authname =3D> 'cn=3Dauthc2',
}
);
$mesg =3D $ldap->bind( 'cn=3Dauthc1', sasl =3D> $sasl );
30 37 02 01 01 60 32 02 01 03 04 09 63 6e 3d 61 07...`2.....cn=3Da
75 74 68 63 31 a3 22 04 05 50 4c 41 49 4e 04 19 uthc1."..PLAIN..
63 6e 3d 61 75 74 68 7a 00 63 6e 3d 61 75 74 68 cn=3Dauthz.cn=3Dauth
63 32 00 73 65 63 72 65 74 c2.secret
--=20
Dipl.-Inform. Norbert Klasen
DAASI International GmbH phone: +49 7071 29 70336
Wilhelmstr. 106 fax: +49 7071 29 5114
72074 T=FCbingen email: nor...@da...
Germany web: http://www.daasi.de
|
|
From: Kurt D. Z. <Ku...@Op...> - 2002-05-08 16:25:12
|
At 08:30 AM 2002-05-08, Norbert Klasen wrote:
>--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote:
>
>>The reason it was using user, was for compatability with previous SASL
>>implementation.
>
>How am I supposed to call Authen::SASL->new and Net::LDAP->bind if I don't want to do proxy auth (ie. not specify an authorization identity with the user callback)?
>
>I'm asking this because in Net/LDAP.pm line 242 "user" defaults to
>'dn: <DN>', where <DN> is the first parameter to NET::LDAP::bind():
> # Tell the SASL object our user identifier
> $sasl->callback( user => "dn: $stash{name}")
> unless $sasl->callback('user');
that's bad. The bind name, SASL authentication identity
(where applicable), and SASL authorization identity (where
applicable and desired) should be provided separately
by the application. It is inappropriate for the API to
assume any particular relationship between them.
I note as well, that "dn: cn=foo" is an invalid LDAP
authzid. There should be no space after the ":".
>BTW how is a server to respond, if it receives different authCids in the name and credentials component of a bind request?
Generally speaking, when SASL is being used, the clients should
not provide a bind name and server should ignore the bind name
if present. RFC 2829 wasn't exactly clear on this, but the
LDAPbis revised specification (a work in progress) should be.
|
|
From: Graham B. <gb...@po...> - 2002-05-08 16:59:33
|
You can add user => sub { '' } into the argument to SASL->new
This is unfortunate historic mistake that should be deprecated
Graham.
On Wed, May 08, 2002 at 09:25:00AM -0700, Kurt D. Zeilenga wrote:
> At 08:30 AM 2002-05-08, Norbert Klasen wrote:
>
>
> >--On Dienstag, 7. Mai 2002 13:38 +0100 Graham Barr <gb...@po...> wrote:
> >
> >>The reason it was using user, was for compatability with previous SASL
> >>implementation.
> >
> >How am I supposed to call Authen::SASL->new and Net::LDAP->bind if I don't want to do proxy auth (ie. not specify an authorization identity with the user callback)?
> >
> >I'm asking this because in Net/LDAP.pm line 242 "user" defaults to
> >'dn: <DN>', where <DN> is the first parameter to NET::LDAP::bind():
> > # Tell the SASL object our user identifier
> > $sasl->callback( user => "dn: $stash{name}")
> > unless $sasl->callback('user');
>
> that's bad. The bind name, SASL authentication identity
> (where applicable), and SASL authorization identity (where
> applicable and desired) should be provided separately
> by the application. It is inappropriate for the API to
> assume any particular relationship between them.
>
> I note as well, that "dn: cn=foo" is an invalid LDAP
> authzid. There should be no space after the ":".
>
> >BTW how is a server to respond, if it receives different authCids in the name and credentials component of a bind request?
>
> Generally speaking, when SASL is being used, the clients should
> not provide a bind name and server should ignore the bind name
> if present. RFC 2829 wasn't exactly clear on this, but the
> LDAPbis revised specification (a work in progress) should be.
>
|
|
From: Kurt D. Z. <Ku...@Op...> - 2002-05-07 17:42:20
|
At 02:36 AM 2002-05-07, Norbert Klasen wrote: >Hi, >RFC2222 says that in the EXTERNAL mechanism "The client sends an initial response with the authorization identity." It also says: If the client sends the empty string as the authorization identity... Unless the client is attempting proxy authorization, the client should send an empty string. This has been discussed in great detail on the iet...@im... mailing list. Kurt |
|
From: Norbert K. <nor...@da...> - 2002-05-08 07:33:52
Attachments:
external-authzid.patch.txt
|
--On Dienstag, 7. Mai 2002 10:42 -0700 "Kurt D. Zeilenga"=20 <Ku...@Op...> wrote: >> Hi, >> RFC2222 says that in the EXTERNAL mechanism "The client sends an initial >> response with the authorization identity." > > It also says: > If the client sends the empty string as the authorization identity... > > Unless the client is attempting proxy authorization, the client > should send an empty string. This has been discussed in great > detail on the iet...@im... mailing list. Seems I mixed up the terminology. Just to be sure: authname =3D authENTICATION identity user =3D authORIZATION identity Correct? Nevertheless, the EXTERNAL mechanism has only one round trip so that the=20 authorize-id needs to be send in client_start. client_step will never get=20 called and can be removed. Also, the noanonymous flag can be set. See=20 attached patch. --=20 Dipl.-Inform. Norbert Klasen DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X