You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Daniel Kahn Gillmor <dk...@fifthhorseman.net> on 2009/10/30 20:27:38 UTC
symmetry of pluggable authentication classes?
hey folks--
i just learned about mina -- looks neat, thanks for offering it!
i'm interested in the configurable authentication classes, as documented
here:
http://mina.apache.org/sshd/configuring-security.html
I note that the PasswordAuthenticator and PublickeyAuthenticator
interfaces are oddly asymmetric: PasswordAuthenticator returns a
non-null identity object if the authentication succeeds, but
PublickeyAuthenticator simply returns a boolean. Why is this?
Also, should either authenticator do anything with the ServerSession
object passed in? There does not seem to be any comment about that
parameter in the interface file.
(please excuse me if i have the terminology wrong -- i don't know much
java, and would appreciate any corrections or suggestions about
terminology or ways to think about these things more clearly).
Regards,
--dkg
Re: symmetry of pluggable authentication classes?
Posted by Guillaume Nodet <gn...@gmail.com>.
You're right. I'll raise a JIRA and fix those interfaces. Thx for reporting.
On Fri, Oct 30, 2009 at 20:27, Daniel Kahn Gillmor
<dk...@fifthhorseman.net> wrote:
> hey folks--
>
> i just learned about mina -- looks neat, thanks for offering it!
>
> i'm interested in the configurable authentication classes, as documented
> here:
>
> http://mina.apache.org/sshd/configuring-security.html
>
> I note that the PasswordAuthenticator and PublickeyAuthenticator
> interfaces are oddly asymmetric: PasswordAuthenticator returns a
> non-null identity object if the authentication succeeds, but
> PublickeyAuthenticator simply returns a boolean. Why is this?
>
> Also, should either authenticator do anything with the ServerSession
> object passed in? There does not seem to be any comment about that
> parameter in the interface file.
>
> (please excuse me if i have the terminology wrong -- i don't know much
> java, and would appreciate any corrections or suggestions about
> terminology or ways to think about these things more clearly).
>
> Regards,
>
> --dkg
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: symmetry of pluggable authentication classes?
Posted by Shawn Pearce <so...@google.com>.
On Fri, Nov 13, 2009 at 09:08, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, it may make more sense to always return a boolean then. Wdyt ?
I think boolean makes more sense as a return, its the result of the
authentication operation, "true" they are permitted, "false" they are
not. If the authenticator cares about attaching more than the
username to the session for downstream usage, its got the session
available to do that with an Attribute. If it doesn't, it can happily
ignore the whole mess and simply return its status.
Returning Object is a bit sloppy, we are overloading null to mean "I
hate you go away", and the return type isn't type safe. E.g. its easy
to make your PasswordAuthenticator return a different type of user
data than your PublicKeyAuthenticator, and downstream get surprised
when one type of authentication results in an unexpected
ClassCastException. The Attribute stuff on ServerSession tries to
reduce the chances of that sort of runtime surprise. (Though it does
nothing to ensure both authenticators actually populated the
Attributes your downstream code cares about.)
> Btw, I've done quite a bit of refactoring on the shell / commands
> interfaces, so it will break any existing app (though the changes are
> quite easy to do).
Yea, I've noticed. Shouldn't take me long to update, I just haven't
had the time to pick up a newer snapshot from trunk. Minor API
breakages are an accepted risk for using a project still under active
development. :-)
Re: symmetry of pluggable authentication classes?
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, it may make more sense to always return a boolean then. Wdyt ?
Btw, I've done quite a bit of refactoring on the shell / commands
interfaces, so it will break any existing app (though the changes are
quite easy to do).
On Fri, Nov 13, 2009 at 16:00, Shawn Pearce <so...@google.com> wrote:
> On Fri, Oct 30, 2009 at 11:27, Daniel Kahn Gillmor
> <dk...@fifthhorseman.net> wrote:
>>
>> http://mina.apache.org/sshd/configuring-security.html
>>
>> Also, should either authenticator do anything with the ServerSession
>> object passed in? There does not seem to be any comment about that
>> parameter in the interface file.
>
> The ServerSession parameter is there so the authenticator can attach
> session attributes via setAttribute(AttributeKey<T> key). E.g. one of
> my applications uses this to attach the application specific object
> which represents a user and what they are permitted to access once the
> session has been established. This is later then available to the
> CommandFactory, and can be given to any Command implementations it
> constructs.
>
> But if all you care about is yes-allow/no-deny, the parameter doesn't
> need to be used.
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: symmetry of pluggable authentication classes?
Posted by Shawn Pearce <so...@google.com>.
On Fri, Oct 30, 2009 at 11:27, Daniel Kahn Gillmor
<dk...@fifthhorseman.net> wrote:
>
> http://mina.apache.org/sshd/configuring-security.html
>
> Also, should either authenticator do anything with the ServerSession
> object passed in? There does not seem to be any comment about that
> parameter in the interface file.
The ServerSession parameter is there so the authenticator can attach
session attributes via setAttribute(AttributeKey<T> key). E.g. one of
my applications uses this to attach the application specific object
which represents a user and what they are permitted to access once the
session has been established. This is later then available to the
CommandFactory, and can be given to any Command implementations it
constructs.
But if all you care about is yes-allow/no-deny, the parameter doesn't
need to be used.