We will be fixing this issue as part of the linked issue CWD-1672 in 2.0.2.

Hi Justin!

I've attached a repro-project that demonstrates the issues I'm having. It's a console-application that prints various assertions to the console. They should all succeed.

• I'm using an Internal Directory.
• I only use the SOAP-API.
• I don't use LDAP.
• The "Allow All To Authenticate" flag is set to true for the directory associated with my test application.

I have two cases (new and existing user) and am also showing the authentication issue I mentioned in the forum (http://forums.atlassian.com/thread.jspa?threadID=36052&tstart=0)

New User:

1. I create a new user (including a custom attribute) using the SOAP API (addPrincipal).
2. I add a second custom attribute (updatePrincipalAttribute).
3. I get the user (findPrincipalByName).
   -> Only the primary attributes are returned.
   -> In the web-interface I can only see the attribute that was added after the user was created
4. I use the password specified during creation to attempt a login (authenticatePrincipal).
   -> The login is fails. If I update the password in the web-interface, the login with the new password succeeds.

Existing User:

1. I have an existing user (created using Crowd's web-interface).
2. I update an existing custom attribute (updatePrincipalAttribute).
   -> Only the primary attributes are returned.
   -> In the web-interface I can see that the update on the custom attribute was # I use the password specified in the web-interface to attempt a login (authenticatePrincipal).
   successful.
   -> The login is successful.

You mentioned

I know I can add and modify both primary and custom attributes for a user, the only limitation currently is returning custom attributes in our SecurityServer API is currently not available.

This worked in Crowd 1.6 and is a required feature for the application I'm building. Was this changed in Crowd 2.0?

Thanks for the quick response,
Michael

Hi Michael,

Could you please attach your testcase to this issue? Specifically I just want to know the execution path you are taking. Are you calling update on a principal from the SecurityServer, or are you attempting to call storeAttributes on the RemoteDirectory interface?

We currently do not allow the adding of custom attributes to LDAP directories, but we do allow the updating of primary attributes for a user in LDAP (givenName, sn, email, displayName).

Calling

void updatePrincipalAttribute(AuthenticatedToken applicationToken, String name, SOAPAttribute attribute)

on the SecurityServerClient will inspect the SOAPAttribute and determine if the attribute is primary or not, if it is primary it will call updateUser, if the attribute is not a primary attribute, it will call storeUserAttributes. Currently storeAttributes will throw an UnsupportedOperationException if you are using an LDAP directory.

We have an open issue for custom attributes in LDAP here CWD-583

If you are using an Internal Directory we support both, so if this is the problem please let me know. I know I can add and modify both primary and custom attributes for a user, the only limitation currently is returning custom attributes in our SecurityServer API is currently not available.