JBossDeveloper

with witch ldap server are you working?
and what schema are you using?
Beacause you must set the next variables:

<property name="username">cn=admin,dc=nodomain</property>

<property name="password">password</property>

<property name="identityOu">People</property>

<property name="roleOu">roles</property>

Yes, it is hard coded at org.jboss.security.idm.ldap.LDAPIdentityProvider, this is the snippet where the active property is setted:

 String cour = rs.getString("sn");
 boolean active = (new Boolean(cour)).booleanValue();
 String pass = rs.getString("userPassword");
 String givenName = rs.getString("givenName");
 String companyName = rs.getString("o");
 String companyRole = rs.getString("employeeType");
 String companyTitle = rs.getString("title");
 String postalAddress = rs.getString("postalAddress");

 //populate the identity
 identity = new Identity();
 identity.setUserName(cn);
 identity.setPassword(pass.getBytes());
 identity.setActive(active);

I am currently trying to setup Fedora Directory Server. But also have tested with OpenLDAP. Yes, the fields are setup properly, I checked the LDAP logs and the server responds correctly ...
But Web Application does not understand. Did you succeed to login in test app?

Yes... with openldap and opends.. with diferent configurations.
Here is my schema for open ldap.

# Base
dn: dc=nodomain
dc: foo
objectClass: top
objectClass: dcObject
objectClass: organization
o: No Domain


# People ou where we attach the users
dn: ou=People, dc=nodomain
ou: People
objectClass: top
objectClass: organizationalUnit

# A basic inetOrgPerson
dn: cn=user,ou=People, dc=nodomain
sn: true
userPassword: secret
mail: user@foo.bar
displayName: user
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: test
cn: user

# The ou where we attach roles/groups
dn: ou=roles, dc=nodomain
ou: roles
objectClass: top
objectClass: organizationalUnit

# A test group member of roles ou
dn: cn=TestGroup,ou=roles, dc=nodomain
ou: TestGroup
objectClass: top
objectClass: groupOfUniqueNames
uniqueMember: cn=user,ou=People
cn: TestGroup

<login-module code="org.jboss.security.idm.UsernameAndPasswordLoginModule" flag="sufficient">

 <module-option name="unauthenticatedIdentity">guest</module-option>

 <module-option name="password-stacking">useFirstPass</module-option>

 <!--module-option name="hashAlgorithm">SHA-1</module-option-->

 <module-option name="hashUserPassword">false</module-option>
 <module-option name="hashStorePassword">false</module-option>

 <module-option name="authenticatedRoles">Authenticated,RegisteredUsers</module-option>

 </login-module>

"yyovkov" wrote:
I am currently trying to setup Fedora Directory Server. But also have tested with OpenLDAP. Yes, the fields are setup properly, I checked the LDAP logs and the server responds correctly ...
But Web Application does not understand. Did you succeed to login in test app?

First, thank you for your attention.

Here is the log from jboss server, during unsuccessful login:
--- cut ---
Apr 2008 00:14:13>
2008-04-05 00:14:13,931 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass
2008-04-05 00:14:13,931 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass
2008-04-05 00:14:13,931 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass
--- cut ---

And here is the LDAP log:
--- cut --
05/Apr/2008:00:14:03 +0300] conn=66 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[05/Apr/2008:00:14:03 +0300] conn=66 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[05/Apr/2008:00:14:03 +0300] conn=66 op=1 SRCH base="cn=Test User,ou=People,dc=yyovkov,dc=net" scope=2 filter="(objectClass=*)" attrs="cn"
[05/Apr/2008:00:14:03 +0300] conn=66 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[05/Apr/2008:00:14:03 +0300] conn=66 op=2 UNBIND
[05/Apr/2008:00:14:03 +0300] conn=66 op=2 fd=67 closed - U1
[05/Apr/2008:00:14:03 +0300] conn=67 fd=68 slot=68 connection from 127.0.0.1 to 127.0.0.1
[05/Apr/2008:00:14:03 +0300] conn=67 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[05/Apr/2008:00:14:03 +0300] conn=67 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[05/Apr/2008:00:14:03 +0300] conn=67 op=1 SRCH base="cn=Test User,ou=People,dc=yyovkov,dc=net" scope=2 filter="(objectClass=*)" attrs="cn sn userPassword givenName displayName o employeeType title postalAddress mail telephoneNumber"
[05/Apr/2008:00:14:03 +0300] conn=67 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[05/Apr/2008:00:14:03 +0300] conn=67 op=2 UNBIND
[05/Apr/2008:00:14:03 +0300] conn=67 op=2 fd=68 closed - U1
[05/Apr/2008:00:14:03 +0300] conn=68 fd=67 slot=67 connection from 127.0.0.1 to 127.0.0.1
[05/Apr/2008:00:14:03 +0300] conn=68 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[05/Apr/2008:00:14:03 +0300] conn=68 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[05/Apr/2008:00:14:03 +0300] conn=68 op=1 SRCH base="cn=Test User,ou=People,dc=yyovkov,dc=net" scope=2 filter="(objectClass=*)" attrs="cn"
[05/Apr/2008:00:14:03 +0300] conn=68 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[05/Apr/2008:00:14:03 +0300] conn=68 op=2 UNBIND
[05/Apr/2008:00:14:03 +0300] conn=68 op=2 fd=67 closed - U1
[05/Apr/2008:00:14:03 +0300] conn=69 fd=68 slot=68 connection from 127.0.0.1 to 127.0.0.1
[05/Apr/2008:00:14:03 +0300] conn=69 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[05/Apr/2008:00:14:03 +0300] conn=69 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[05/Apr/2008:00:14:03 +0300] conn=69 op=1 SRCH base="cn=Test User,ou=People,dc=yyovkov,dc=net" scope=2 filter="(objectClass=*)" attrs="cn sn userPassword givenName displayName o employeeType title postalAddress mail telephoneNumber"
[05/Apr/2008:00:14:03 +0300] conn=69 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[05/Apr/2008:00:14:03 +0300] conn=69 op=2 UNBIND
[05/Apr/2008:00:14:03 +0300] conn=69 op=2 fd=68 closed - U1

--- cut ---

Hm ... I think I found where is the problem. The user: cn=user... doesn't have sufficient rights to read the directory. So I will change settings into directory Tree and will post result here. Probably tomorrow.

Thank you for your help!

Alejandro and Mauricio are correct.

The LDAPIdentityProvider is designed to use the InetOrgPerson schema which is standard LDAP schema.

However, I think the use of cn and sn in its current implementation is not correct.

I would prefer to use uid instead of cn, and still not sure how to represent the "activation" field.

using sn is confusing.

I initially used these, since the LDAP repo that I was connecting with had the data setup that way.

However, its time the out-of-the-box LDAP impl moves away from that semantics and uses uid and something else for representing "account activation"

Part of the reason I have not changed it, is also keeping backward compatibility with existing users who have setup their LDAP repo based on this impl.

I think the cleanest approach will be leave this LDAPIdentityProvider impl as is, and introduce a new one that maps the data in a more standard manner.

I apologize for the confusion that the hackish usage of 'sn' created ;)

If I were Hillary Clinton then I would say "I mis-coded" ;)

Thanks

Guys-

You can track this issue here: http://jira.jboss.com/jira/browse/JBSSO-37

Until then when using the out-of-the-box impl make sure the 'sn' field in your repo is used to represent "true' or "false" value that indicates whether an account is activated or not.

You can ofcourse create your own IdentityProvider or extend this to fit whatever schema you have set up in your environment

Thanks

Hi all,

I believe I found where is the problem with jboss sso and Fedora Directory Server (FDS). Here is some short explanation:

When using LDAP and you set user password, OpenLDAP server store the password as plaintext. But FDS always store this value as hashed string (SSHA, MD5 ... so on). So it means that Authentication module should be aware of how the password is stored.

Btw, is JBoss SSO is actively developing or not?

change the configuration in the jboss-sso-test.ear/META-INF/security-config.xml

<login-module code="org.jboss.security.idm.UsernameAndPasswordLoginModule" flag="sufficient">

 <module-option name="unauthenticatedIdentity">guest</module-option>

 <module-option name="password-stacking">useFirstPass</module-option>

 <!--module-option name="hashAlgorithm">SHA-1</module-option-->

 <module-option name="hashUserPassword">false</module-option>
 <module-option name="hashStorePassword">false</module-option>

 <module-option name="authenticatedRoles">Authenticated,RegisteredUsers</module-option>

 </login-module>

take a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=133123 If you have doubts about how to use it, please do not post it at the "Design of security" forum, do it here.

Hi Salaboy,

thank you for the information about test application.
Unfortunately I did not succeed.
As I am very beginner in Java at all can you introduce me how does the settings must look like when the LDAP is setup to store the passwords in MD5 hash?

Thank you in advance!

If you are use Fedora DS and it only save the password in a MD5, try to configurate it to store it in Plain format...
Today, i´m doing the integration with openDS and I found a bug with hashed passwords in a crossdomain test...

If you are trying only to sign up in one domain your configuration in the test application will be something like this:

<login-module code="org.jboss.security.idm.UsernameAndPasswordLoginModule" flag="sufficient">

 <module-option name="unauthenticatedIdentity">guest</module-option>

 <module-option name="password-stacking">useFirstPass</module-option>

 <!--module-option name="hashAlgorithm">MD5</module-option-->

 <module-option name="hashUserPassword">true</module-option>
 <module-option name="hashStorePassword">false</module-option>

 <module-option name="authenticatedRoles">Authenticated,RegisteredUsers</module-option>

 </login-module>

Hi salaboy21,

here is my security-config.xml
--- cut ---
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd">

<!-- The JAAS login configuration file for the java:/jaas/jbossweb-form-auth
security domain used by the security-spec test case
-->

<application-policy name="jboss-sso">

<login-module code="org.jboss.security.idm.UsernameAndPasswordLoginModule" flag="sufficient">
<module-option name="unauthenticatedIdentity">guest</module-option>
<module-option name="password-stacking">useFirstPass</module-option>
<!--module-option name="hashAlgorithm">MD5</module-option>
<module-option name="hashEncoding">HEX</module-option-->

<module-option name="hashUserPassword">true</module-option>
<module-option name="hashStorePassword">false</module-option>

<module-option name="authenticatedRoles">Authenticated,RegisteredUsers</module-option>
</login-module>
<login-module code="org.jboss.security.idm.UsernameAndPasswordLoginModule" flag="sufficient">
<module-option name="unauthenticatedIdentity">guest</module-option>
<module-option name="password-stacking">useFirstPass</module-option>
<module-option name="authenticatedRoles">Authenticated,RegisteredUsers</module-option>
</login-module>

</application-policy>

--- cut ---

I am still not able to connect to FedoraDS. I have also tried to connect to OpenLDAP server, but with changed password of the user to be MD5 hashed, not playntext. It also did not work.