Jeremy, you bring up some good points (caching authc info if a user wants us to). Can you please open a Jira issue to address this? That way we have it as a place holder during discussion.
On Wed, Mar 25, 2009 at 1:05 PM, Jeremy Haile <[email protected]> wrote: > Maciej, > > The problem is that if the LDAP server requires credentials to login (as > they typically do), there is no way to obtain authorization information at a > later point without having a username/password to login to the LDAP server. > Due to the way JSecurity works, authentication and authorization happen > independently of each other, and so when authorization occurs we do not have > the username/password that was originally used to authenticate (as we > shouldn't). > > I think this brings to light an option that JSecurity should offer - which > is to allow authorization information to be obtained at login and cached for > the duration of a user's session. This is the way many security frameworks > operate, and usually we tout the fact that JSecurity doesn't work this way > as an advantage (i.e. dynamic security updates, flexible caching, etc.) > > However - in this case it's a disadvantage because login is the only time > when we have the information we need to obtain the authorization information > (since the authentication info is needed to obtain it). I think there will > be other scenarios where this is the case (external authorization systems, > SSO systems, etc.) so I do think JSecurity should offer this mechanism as an > option. I'll open a JIRA issue to address this for the 1.0 release. > > As far as a short-term workaround, you could either: > 1) configure the system username and password for now (as I think you've > already done) > or > 2) extend the Active Directory realm, and override > queryForAuthenticationInfo to grab the AuthorizationInfo (similar to how > queryForAuthorizationInfo does) at login. You could then cache the > AuthorizationInfo in the subject's session and override > queryForAuthorizationInfo to return the session-cached authorization > information. This is similar to how JSecurity would probably do this in the > future, but obviously you'd have to manually implement it. > > Please let me know if you have any further questions or ideas! > > Jeremy > > > On Mar 25, 2009, at 12:24 PM, Maciej Pigulski wrote: > > >> Unfortunately this is still an issue to me. >> >> >> Jeremy or Tim, do you know if you'd be able to help out Maciej? I don't >> have any experience with the LDAP/AD stuff you guys wrote. Maciej, have >> you been able to work through this issue? >> >> On Thu, Mar 19, 2009 at 9:46 AM, Maciej Pigulski >> <[email protected]>wrote: >> >> >>> Hello, >>> >>> I have a following problem with jSecurity, ActiveDirectoryRealm and >>> Groups >>> mappings. >>> >>> I have an AD setup on one server (WHEEL) with a simple user called user1. >>> This user is in ldap group called "login" (CN=login,OU=Groups,DC=WHEEL). >>> >>> Next I'm trying to login and retrieve roles for this user. Login works >>> fine >>> but when it comes to user roles I have to additionally provide username >>> and >>> password in activeDirectoryRealm.setSystemUsername/Password. I've found >>> in >>> the API that it is a pretty normal behaviour (but IMHO very inconvenient) >>> ( >>> >>> http://www.jsecurity.org/releases/0.9.0-beta2/docs/api/org/jsecurity/realm/ldap/DefaultLdapContextFactory.html#setSystemUsername(java.lang.String)<http://www.jsecurity.org/releases/0.9.0-beta2/docs/api/org/jsecurity/realm/ldap/DefaultLdapContextFactory.html#setSystemUsername%28java.lang.String%29> >>> < >>> http://www.jsecurity.org/releases/0.9.0-beta2/docs/api/org/jsecurity/realm/ldap/DefaultLdapContextFactory.html#setSystemUsername%28java.lang.String%29 >>> > >>> : >>> <cite> >>> systemUsername - the username to use when logging into the LDAP server >>> for >>> authorization. >>> </cite> >>> >>> Is there any tricky way to bypass this? Setting same credentials on two >>> objects to authorize and authenticate one user seems to be quite wrong. >>> >>> I've managed to obtain this by creating a super user (with enterprise >>> administrator rights) that has hardcoded username and password in >>> application (systemUsername and systemPassword) and this works for >>> authenticating other users but I'd like to avoid using such powerfull >>> user >>> just for groups fetching as it seems to be an huge overkill for me. >>> >>> Here is a class I'm using to test with AD: >>> >>> import java.util.HashMap; >>> import java.util.Map; >>> >>> import org.jsecurity.authc.UsernamePasswordToken; >>> import org.jsecurity.mgt.DefaultSecurityManager; >>> import org.jsecurity.realm.activedirectory.ActiveDirectoryRealm; >>> import org.jsecurity.subject.Subject; >>> >>> public class TestJSec { >>> >>> private DefaultSecurityManager securityManager = new >>> DefaultSecurityManager(); >>> private ActiveDirectoryRealm activeDirectoryRealm = new >>> ActiveDirectoryRealm(); >>> >>> public TestJSec() { >>> activeDirectoryRealm.setSearchBase("DC=WHEEL"); >>> activeDirectoryRealm.setUrl("ldap://ldap-host:389";); >>> activeDirectoryRealm.setSystemUsername("us...@wheel"); // >>> if this is >>> missing user wont fetch his roles >>> activeDirectoryRealm.setSystemPassword("user1"); >>> // if this >>> is missing user wont fetch his roles >>> Map<String, String> map = new HashMap<String, String>(); >>> map.put("CN=login,OU=Groups,DC=WHEEL", "login"); >>> activeDirectoryRealm.setGroupRolesMap(map); >>> >>> securityManager.setRealm(activeDirectoryRealm); >>> } >>> >>> private void testLogin() { >>> UsernamePasswordToken userToken = new >>> UsernamePasswordToken("us...@wheel", >>> "user1"); >>> >>> Subject subject = securityManager.login(userToken); >>> if (subject.hasRole("login")) { >>> System.out.println("User in role"); >>> } else { >>> System.out.println("User has no role"); >>> } >>> } >>> >>> public static void main(String[] args) { >>> TestJSec tjs = new TestJSec(); >>> tjs.testLogin(); >>> } >>> } >>> >>> >>> For example in jBoss this config works without a super user: >>> >>> >>> <application-policy name="DLG_REGW_POLICY"> >>> <authentication> >>> <login-module >>> code="org.jboss.security.auth.spi.LdapLoginModule" >>> flag="required" > >>> <module-option >>> name="java.naming.provider.url">ldap://ldap-host:389/</module-option> >>> <module-option >>> name="rolesCtxDN">OU=Groups,DC=WHEEL</module-option> >>> <module-option >>> name="matchOnUserDN">false</module-option> >>> <module-option >>> name="uidAttributeID">sAMAccountName</module-option> >>> <module-option >>> name="roleAttributeID">memberOf</module-option> >>> <module-option >>> name="roleAttributeIsDN">true</module-option> >>> <module-option >>> name="roleNameAttributeID">name</module-option> >>> <module-option >>> name="searchTimeLimit">5000</module-option> >>> <module-option >>> name="allowEmptyPasswords">false</module-option> >>> <module-option >>> name="searchScope">SUBTREE_SCOPE</module-option> >>> </login-module> >>> </authentication> >>> </application-policy> >>> >>> -- >>> View this message in context: >>> >>> http://n2.nabble.com/Reading-user-roles-from-Active-Directory-tp2503002p2503002.html >>> Sent from the JSecurity User mailing list archive at Nabble.com. >>> >>> >>> >> >> >> -- >> View this message in context: >> http://n2.nabble.com/Reading-user-roles-from-Active-Directory-tp2503002p2533411.html >> Sent from the JSecurity User mailing list archive at Nabble.com. >> >> >
