You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Adam Taft <ad...@adamtaft.com> on 2008/12/02 06:26:08 UTC
SSH and Native Host Authentication Methods
Hi,
I'm currently writing a JSecurity Realm which uses SSH to authenticate
with a remote host. I'm extending AuthenticatingRealm to do this, and
using the Trilead SSH library.
http://www.trilead.com/Products/Trilead_SSH_for_Java/
This concept is coming along nicely and works great for my use case. In
particular, since my target doesn't have any LDAP or Kerberos based
login functionality, SSH is a decent choice and I'm already familiar
with the library.
As well, I also plan to investigate writing an Authorizer which will use
the same SSH connection and essentially request the contents of
/etc/group to determine roles and role memberships. I think this will
be fairly trivial as well, and pretty useful again for those who don't
run a network aware login server. Maybe by parsing /etc/group format
into a TextConfiguration or something.
I'm also looking at a local native host authentication, probably using
the Shaj project (or something similar, if you know of one).
http://opensource.cenqua.com/shaj/
OK, so now my questions:
1) Has anyone attempted an SSH based Realm for JSecurity?
1.a If so, I'd like to not duplicate efforts and would appreciate
knowing about it. I'm not seeing anything in the API like it, or
reading anything on the mailing lists.
1.b If not, then I'd like to solicit feedback on the general
usefulness of such a feature. I can make my code available under the
ASL 2.0 for contribution (though, I need to write an abstraction since
I'm currently tightly coupled with Trilead).
2) Has anyone attempted a native local authentication before? I.e. not
Kerberos, LDAP, or Active Directory, but more like straight unix Crypt
login or NTLM on Winders? Maybe using shaj or some other similar
library? Doesn't Acegi already have something like this?
3) Any other thoughts, directions or potential speed bumps on these two
Realm options?
Thanks much,
Adam Taft
Re: SSH and Native Host Authentication Methods
Posted by Les Hazlewood <lh...@apache.org>.
Hrm. I didn't see anything attached (I dunno if you're allowed to post
attachments to an ASF mailing list). Can you repost this message into a
Jira issue and attach the code there?
On Thu, Dec 4, 2008 at 9:34 PM, Adam Taft <ad...@adamtaft.com> wrote:
> Hi,
>
> I apologize in advance for what will likely be a lengthy message. I
> tend to be more verbose than most. :)
>
> So I'm attaching my source code to this email which attempts to
> address my use case of using SSH for authentication and authorization.
>
> Again, my use case is to:
>
> a) Perform authentication with a remote SSH server
>
> b) Use said connection to extract the subject's role information from
> /etc/group (a linux server).
>
> In order to accomplish this, I wrote a class called
> SingleSourceRealmAdapter (attached) which basically merges the two
> doGetAuthxyz() methods from AuthorizingRealm into a single
> getAccount() method. I'm using a ConcurrentHashMap to store the
> relation between a Principal and an Account. Hopefully this helps
> someone else out there.
>
> As an example, for my use case, I want to create a single SSH
> connection which both authenticates the user as well as extracts his
> role information. I don't want to bring up a connection and tear it
> down in doGetAuthenticationInfo() only to be setting up and tearing
> down a connection in doGetAuthorizationInfo(). I want both
> authentication and authorization information extracted in the same
> connection.
>
> Likewise, for an LDAP server implementation, it's generally considered
> best practice to use the subject's credentials to bind to the LDAP
> server and validate authentication. At that point, it's appropriate
> to also extract the user's role memberships, which in LDAP's case, is
> generally stored in a key which the user has permission to read.
>
> What happens now, for example in AbstractLdapRealm, is that a super
> user of sorts is used for the LDAP connection to extract credentials
> which a CredentialsMatcher evaluates. This may not work for some LDAP
> servers configurations, since often a super user connection may not
> even be exposed, or the password hashing algorithm may not be straight
> forward.
>
> Again, the alternative (possibly preferred?) approach is to bind to
> the LDAP server using the subject's credentials and not that of a
> super user. The JSecurity side should never have to see or match the
> subject's credentials with an LDAP server authentication, and a super
> user account should not be needed to authenticate or authorize against
> LDAP.
>
> This is the reasoning behind SingleSourceRealmAdapter. Your comments
> are appreciated. One thing I didn't know about is how role or
> permission changes are propagated throughout the various Realms.
> Since I'm using a Map to store the relation between a Principal and an
> Account, I'm not sure how to listen for a change of role or
> permissions and clean the appropriate Map entries.
>
> Additionally, I'm thinking it would likely be better to use the
> underlying CacheManager to store this mapping, however I am not sure
> if a CacheManager or a Cache is even required, therefore I can't rely
> on its existence.
>
> The other three classes I'm attaching are pretty straight forward and
> simply deal with creating an SSH based realm. You are free to include
> these in your distribution if interested, but they are so trivial as
> to possibly not even be that useful.
>
> Thanks for any feedback.
>
> Adam Taft
>
>
>
>
> On Mon, Dec 1, 2008 at 10:26 PM, Adam Taft <ad...@adamtaft.com> wrote:
> > Hi,
> >
> > I'm currently writing a JSecurity Realm which uses SSH to authenticate
> with
> > a remote host. I'm extending AuthenticatingRealm to do this, and using
> the
> > Trilead SSH library.
> >
> > http://www.trilead.com/Products/Trilead_SSH_for_Java/
> >
> > This concept is coming along nicely and works great for my use case. In
> > particular, since my target doesn't have any LDAP or Kerberos based login
> > functionality, SSH is a decent choice and I'm already familiar with the
> > library.
> >
> > As well, I also plan to investigate writing an Authorizer which will use
> the
> > same SSH connection and essentially request the contents of /etc/group to
> > determine roles and role memberships. I think this will be fairly
> trivial
> > as well, and pretty useful again for those who don't run a network aware
> > login server. Maybe by parsing /etc/group format into a
> TextConfiguration
> > or something.
> >
> > I'm also looking at a local native host authentication, probably using
> the
> > Shaj project (or something similar, if you know of one).
> >
> > http://opensource.cenqua.com/shaj/
> >
> > OK, so now my questions:
> >
> > 1) Has anyone attempted an SSH based Realm for JSecurity?
> >
> > 1.a If so, I'd like to not duplicate efforts and would appreciate
> knowing
> > about it. I'm not seeing anything in the API like it, or reading
> anything
> > on the mailing lists.
> >
> > 1.b If not, then I'd like to solicit feedback on the general usefulness
> of
> > such a feature. I can make my code available under the ASL 2.0 for
> > contribution (though, I need to write an abstraction since I'm currently
> > tightly coupled with Trilead).
> >
> > 2) Has anyone attempted a native local authentication before? I.e. not
> > Kerberos, LDAP, or Active Directory, but more like straight unix Crypt
> login
> > or NTLM on Winders? Maybe using shaj or some other similar library?
> > Doesn't Acegi already have something like this?
> >
> > 3) Any other thoughts, directions or potential speed bumps on these two
> > Realm options?
> >
> > Thanks much,
> >
> > Adam Taft
> >
> >
>
Re: SSH and Native Host Authentication Methods
Posted by Adam Taft <ad...@adamtaft.com>.
Hi,
I apologize in advance for what will likely be a lengthy message. I
tend to be more verbose than most. :)
So I'm attaching my source code to this email which attempts to
address my use case of using SSH for authentication and authorization.
Again, my use case is to:
a) Perform authentication with a remote SSH server
b) Use said connection to extract the subject's role information from
/etc/group (a linux server).
In order to accomplish this, I wrote a class called
SingleSourceRealmAdapter (attached) which basically merges the two
doGetAuthxyz() methods from AuthorizingRealm into a single
getAccount() method. I'm using a ConcurrentHashMap to store the
relation between a Principal and an Account. Hopefully this helps
someone else out there.
As an example, for my use case, I want to create a single SSH
connection which both authenticates the user as well as extracts his
role information. I don't want to bring up a connection and tear it
down in doGetAuthenticationInfo() only to be setting up and tearing
down a connection in doGetAuthorizationInfo(). I want both
authentication and authorization information extracted in the same
connection.
Likewise, for an LDAP server implementation, it's generally considered
best practice to use the subject's credentials to bind to the LDAP
server and validate authentication. At that point, it's appropriate
to also extract the user's role memberships, which in LDAP's case, is
generally stored in a key which the user has permission to read.
What happens now, for example in AbstractLdapRealm, is that a super
user of sorts is used for the LDAP connection to extract credentials
which a CredentialsMatcher evaluates. This may not work for some LDAP
servers configurations, since often a super user connection may not
even be exposed, or the password hashing algorithm may not be straight
forward.
Again, the alternative (possibly preferred?) approach is to bind to
the LDAP server using the subject's credentials and not that of a
super user. The JSecurity side should never have to see or match the
subject's credentials with an LDAP server authentication, and a super
user account should not be needed to authenticate or authorize against
LDAP.
This is the reasoning behind SingleSourceRealmAdapter. Your comments
are appreciated. One thing I didn't know about is how role or
permission changes are propagated throughout the various Realms.
Since I'm using a Map to store the relation between a Principal and an
Account, I'm not sure how to listen for a change of role or
permissions and clean the appropriate Map entries.
Additionally, I'm thinking it would likely be better to use the
underlying CacheManager to store this mapping, however I am not sure
if a CacheManager or a Cache is even required, therefore I can't rely
on its existence.
The other three classes I'm attaching are pretty straight forward and
simply deal with creating an SSH based realm. You are free to include
these in your distribution if interested, but they are so trivial as
to possibly not even be that useful.
Thanks for any feedback.
Adam Taft
On Mon, Dec 1, 2008 at 10:26 PM, Adam Taft <ad...@adamtaft.com> wrote:
> Hi,
>
> I'm currently writing a JSecurity Realm which uses SSH to authenticate with
> a remote host. I'm extending AuthenticatingRealm to do this, and using the
> Trilead SSH library.
>
> http://www.trilead.com/Products/Trilead_SSH_for_Java/
>
> This concept is coming along nicely and works great for my use case. In
> particular, since my target doesn't have any LDAP or Kerberos based login
> functionality, SSH is a decent choice and I'm already familiar with the
> library.
>
> As well, I also plan to investigate writing an Authorizer which will use the
> same SSH connection and essentially request the contents of /etc/group to
> determine roles and role memberships. I think this will be fairly trivial
> as well, and pretty useful again for those who don't run a network aware
> login server. Maybe by parsing /etc/group format into a TextConfiguration
> or something.
>
> I'm also looking at a local native host authentication, probably using the
> Shaj project (or something similar, if you know of one).
>
> http://opensource.cenqua.com/shaj/
>
> OK, so now my questions:
>
> 1) Has anyone attempted an SSH based Realm for JSecurity?
>
> 1.a If so, I'd like to not duplicate efforts and would appreciate knowing
> about it. I'm not seeing anything in the API like it, or reading anything
> on the mailing lists.
>
> 1.b If not, then I'd like to solicit feedback on the general usefulness of
> such a feature. I can make my code available under the ASL 2.0 for
> contribution (though, I need to write an abstraction since I'm currently
> tightly coupled with Trilead).
>
> 2) Has anyone attempted a native local authentication before? I.e. not
> Kerberos, LDAP, or Active Directory, but more like straight unix Crypt login
> or NTLM on Winders? Maybe using shaj or some other similar library?
> Doesn't Acegi already have something like this?
>
> 3) Any other thoughts, directions or potential speed bumps on these two
> Realm options?
>
> Thanks much,
>
> Adam Taft
>
>
Re: SSH and Native Host Authentication Methods
Posted by Les Hazlewood <lh...@apache.org>.
Wow, this one went unanswered for a while. Sorry Adam :(
On Tue, Dec 2, 2008 at 12:26 AM, Adam Taft <ad...@adamtaft.com> wrote:
>
> 1) Has anyone attempted an SSH based Realm for JSecurity?
Not that I'm aware of :/
>
>
> 1.a If so, I'd like to not duplicate efforts and would appreciate knowing
> about it. I'm not seeing anything in the API like it, or reading anything
> on the mailing lists.
>
> 1.b If not, then I'd like to solicit feedback on the general usefulness
> of such a feature. I can make my code available under the ASL 2.0 for
> contribution (though, I need to write an abstraction since I'm currently
> tightly coupled with Trilead).
We'd greatly appreciate this as a contribution. Please open a Jira issue
and attach it - I'd love to check it out! (
https://issues.apache.org/jira/browse/JSEC)
> 2) Has anyone attempted a native local authentication before? I.e. not
> Kerberos, LDAP, or Active Directory, but more like straight unix Crypt login
> or NTLM on Winders? Maybe using shaj or some other similar library?
> Doesn't Acegi already have something like this?
Again, not that I'm aware of. I'm not too knowledgeable on Acegi, so I'm
not sure if they have something similar.
>
>
> 3) Any other thoughts, directions or potential speed bumps on these two
> Realm options?
Sounds like you're going about the right approach - did it work out alright?
Regards,
Les