Is this a group held in an external LDAP server, or in the Gluu Server? If the group is external, and you are using Cache Refresh, then you could use a [custom interception script](http://www.gluu.org/docs/reference/interception-scripts/#update-user) to render this attribute. If you're managing the Group in the LDAP server, OpenDJ has support for a [virtual attribute](http://opendj.forgerock.org/opendj-server/configref/virtual-attribute.html) called memberOf, which can be passed as an attribute to the application.

Hi, There is no custom Object Class for groups. But there are 2 interceptor scripts which allows to do post processing after adding/updating user entry: http://www.gluu.org/docs/reference/interception-scripts/#update-user http://www.gluu.org/docs/reference/interception-scripts/#user-registration Can can use them if they conform your requirements.

What we are trying to do is, Let us suppose we have 4 users(u1,u2,u3,u4) Now u1 and u2 have 3 privileges p1, p2 and p3 Similarly u3 and u4 have 2 privileges p4 and p5 We want to group the users together based on the privileges Say u1 and u2 belongs to group g1, u3 and u4 belongs to group g2 And we want this attribute to be part of scope, preferably "openid", so that we can decrypt the token any where we want and get the privileges information from it. We were thinking is there a way to create a group level attribute say "Privileges" which we can set for each group and each member of that group inherits it. Some of our customers may have an existing ldap server others may not. We are concerned with both the scenarios. If this is not possible can you suggest a way in which we can achieve something similar to it. Thanks, Qasim

Qasim: 1) Definitely do not use scope openid! This scope should just contain the sub user claim. 2) You are saying "groups", but don't use groups. The problem is that when a user logs in, we send his claims. There is no support in federation protocols for grabbing information from a group entity. The way that companies who love groups normally bridge this is by using the memberOf attribute. But my advice is, avoid groups and you won't have to rely on this trick. 3) Define a custom objectclass called "svPerson" and add an attribute called "svPermission" to your OpenLDAP Schema by creating a file called `/opt/opendj/config/schema/102-sv.ldif`: dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema attributeTypes: ( svPermission-oid NAME 'svPermission' SUBSTR caseIgnoreSubstringsMatch EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'SV custom attribute' ) objectClasses: ( svPerson-oid NAME 'svPerson' SUP top AUXILIARY MAY ( svPermission) X-ORIGIN 'SV - Custom objectclass' ) Restart opendj and make sure there are no errors...Then update your oxTrust.properties, adding "svPerson" to the "person-objectClass-types" and "person-objectClass-displayNames" properties and `# touch /opt/tomcat/conf/oxtrust.config.reload"` to get oxTrust to reload the config. (Alternately you could add the attribute through the oxTrust admin UI, but being old-fashioned, I don't like this approach as much...). 4) Register this new attribute using the oxTrust admin interface, in the "Attributes" configuraiton page. In the For SAML URI, you can use an https URI like https://sv.com/schema/svPermission... it doesn't matter, you're not going to use SAML anyway. 5) Create a custom scope called "svInfo" for OpenID Connect 6) Add the svPermission userclaim to this OpenID Connect scope. Make sure you release this scope to your registered clients. Now you have a custom attribute that you can populate with the permissions and send to the applications to map to their local security implementation! We'll create an article on this topic... coming soon.