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 <[email protected]> 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 <[email protected]> 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 > > > > >
