By: Ben Cory user 25 Jul 2017 at 8:43 a.m. CDT

19 Responses
Ben Cory gravatar
Using setAttribute in an authentication script for attributes on GluuPerson works ok. Using setAttribute on GluuCustomPerson in a script causes the following LDAP exception: com.unboundid.ldap.sdk.LDAPException: attribute 'someattribute' not allowed. The gluuCustomPerson attributes can be set though the ox trust admin UI. Once an attribute has been set then any attributes on GluuCustomPerson can be successfully set through an authentication script. The difference I can see is when a user is added the objectClass in LDAP for gluuCustomPerson is not added. This is added when an attribute belonging to gluuCustomPerson is set through the update person in ox trust admin ui. The question is how can attributes be set on a person which belong to gluuCustomPerson if none have been first set through the admin UI ?

By Michael Schwartz Account Admin 25 Jul 2017 at 8:55 a.m. CDT

Michael Schwartz gravatar
You need to update the attribute in LDAP too. Did you follow the instructions on the [Attributes doc page](https://gluu.org/docs/ce/3.0.2/admin-guide/attribute/)?

By Ben Cory user 25 Jul 2017 at 9:04 a.m. CDT

Ben Cory gravatar
Thanks for the quick response Michael. The attributes are setup in ldap. I added them to the gluuCustomPerson class. They can be set ok through the ox trust admin client. The issue is for a new user when no attributes have been set through the UI that belong to the gluuCustomPerson class. If I set at least one gluuCustomPerson class attribute through the UI then setAttribute in the authentication scripts works just fine for attributes belonging to the gluuCustomPerson class.

By Michael Schwartz Account Admin 25 Jul 2017 at 9:08 a.m. CDT

Michael Schwartz gravatar
Interesting... We'll try to verify this issue. It may be a bug. There is a workaround in the script: you can check to see if the `objectclass` is present, and if not, add it.

By Aliaksandr Samuseu staff 25 Jul 2017 at 9:13 a.m. CDT

Aliaksandr Samuseu gravatar
Hi, Ben. I think Michael is right, it's most likely due to missing `objectclass` in the user entry to which you are trying to add it. Let me check our codes, I believe there was a script or two where we set `objectclass` first before working with custom attributes

By Ben Cory user 25 Jul 2017 at 9:21 a.m. CDT

Ben Cory gravatar
Thanks Both, Can you point me at any script as an example for this before I go free style ?

By Michael Schwartz Account Admin 25 Jul 2017 at 9:27 a.m. CDT

Michael Schwartz gravatar
I don't think we have one. We refer custom authentication script development to Centroxy, one of our offshore partners if you need help.

By Ben Cory user 25 Jul 2017 at 9:30 a.m. CDT

Ben Cory gravatar
Thanks for your help, Very much appreciated. Please let me know if this does turn out to be a bug and when a fix is available.

By Aliaksandr Samuseu staff 25 Jul 2017 at 9:37 a.m. CDT

Aliaksandr Samuseu gravatar
[This is](https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/asimba/AsimbaExternalAuthenticator.py) script I had in mind. First we include this: ``` from org.xdi.ldap.model import CustomAttribute ``` Script has property "user_object_classes" which include all objectclasses that must be added to an user entry (the script enrolls new entries on the fly). [Here](https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/asimba/AsimbaExternalAuthenticator.py#L597) they are processed, and then they are added to a new entry at different branches, [here](https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/asimba/AsimbaExternalAuthenticator.py#L685), to name one. This may serve as a workaround, I guess. Please note support for custom scripts is not included into Community support, you'll need to study the rest yourself, it turns out.

By Ben Cory user 25 Jul 2017 at 9:41 a.m. CDT

Ben Cory gravatar
Thank you , Really appreciate it, I will use that as a very good starting point.

By Aliaksandr Samuseu staff 25 Jul 2017 at 1:58 p.m. CDT

Aliaksandr Samuseu gravatar
Could you elaborate a bit on a couple of things that still isn't clear to us, Ben? Where exactly this user entry you have issue with does come from? How is it created? Do you create it via web UI, add it with Cache Refresh, or may be the script itself tries to create it? The former 2 methods actually should ensure `gluuCustomPerson` objectclass is added to the user entry. Could you provide a list of steps which lead to appearing of a user entry with this issue? Also, could you provide LDIF dump of this user entry to us?

By Yuriy Movchan staff 25 Jul 2017 at 2:15 p.m. CDT

Yuriy Movchan gravatar
We need to add `gluuCustomPerson` custom object class to user entry from script. For 3.1.0 I added [issue](https://github.com/GluuFederation/oxAuth/issues/596) to automatically add it.

By Ben Cory user 26 Jul 2017 at 3:17 a.m. CDT

Ben Cory gravatar
There are two routes to creating a user without the gluuCustomPerson object class: 1. Logon to a social site e.g. github and let the passport authentication script intercept and add the user. 2. Use the oxtrust admin GUI to add a new user but do not add any attributes which belong to the gluuCustomPerson object class. With a user created by 1 or 2 try and set an attribute in an authentication script using setAttribute on the user object. [ldif file for person added through the passport authentication script (the first approach)](https://www.dropbox.com/s/bywr2hpc00j7dxr/sampleGluuUserAddedThroughScript.ldif?dl=0) Please let me know if you need any further information.

By Aliaksandr Samuseu staff 26 Jul 2017 at 9:42 a.m. CDT

Aliaksandr Samuseu gravatar
Thanks, Ben. I think the first method is what Yuriy was referencing in his post above. He added an enhancement request for CE 3.1 for the required objecclass to be added to any user entry created with a set of functions used by custom scripts. With older versions you should be fine with a workaround I provided before. The second one is a bit confusing, indeed. Thanks for letting us know, I'll need to reproduce and discuss it with the team.

By Yuriy Movchan staff 26 Jul 2017 at 11:24 a.m. CDT

Yuriy Movchan gravatar
In 3.0.x I offer before saving user entry do something like this: ``` requiredObjectClasses = "gluuCustomPerson, ..." userObjectClasses = StringHelper.split(requiredObjectClasses, ",") user.setCustomObjectClasses(userObjectClasses) ```

By Ben Cory user 26 Jul 2017 at 11:41 a.m. CDT

Ben Cory gravatar
This looks good assuming requiredObjectClasses is read from config. It is my understanding that for a production environment I need to move away from gluuCustomPerson as it may be removed in a future release and create our own class.

By Aliaksandr Samuseu staff 26 Jul 2017 at 11:55 a.m. CDT

Aliaksandr Samuseu gravatar
>It is my understanding that for a production environment I need to move away from gluuCustomPerson as it may be removed in a future release I don't think it will be. Not sure what could give you that impression. It was actually added in 3.0 as substitution for previous way to handle extensions to the LDAP schema. As far as I know, it will stay this way now. You even are expected to put other standard attributes which are not present in Gluu out-of-the-box (like `inetOrgPerson` attributes) into `gluuCustomPerson` manually, when you need them in your user entries.

By Ben Cory user 26 Jul 2017 at 12:32 p.m. CDT

Ben Cory gravatar
Thanks Aliaksandr, It was in conversation with Michael but if the recommended approach is to stay with gluuCustomPerson then I am fine with that.

By Aliaksandr Samuseu staff 28 Jul 2017 at 9:57 a.m. CDT

Aliaksandr Samuseu gravatar
Hi, Ben. I'm testing user creation in web UI in my 3.0.2 instance, and can't confirm the issue. Even when created with only default set of attributes, user still contains `gluuCustomPerson` and `eduPerson` OCs. I guess this may be some old issue of 3.0.1 which is fixed now. I can't add much regarding the `gluuCustomPerson` OC's deprecation, but dev team member responsible for that part isn't aware of such. May be Michael will be able to comment on this. I'm closing the ticket for now, it still be open for comments, if needed.

By Ben Cory user 28 Jul 2017 at 10:05 a.m. CDT

Ben Cory gravatar
Thanks Aliaksandr, I have implemented the work around for 3.0.1. When I build or upgrade to 3.0.2 I will re-test.