Oops - you said you'd do that in the email - sorry I missed it. What is the issue #?
On Mon, Mar 30, 2009 at 1:08 PM, Les Hazlewood <[email protected]>wrote: > 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. >>> >>> >> >
