Revision as of 08:57, 25 February 2009

User Attributes[edit]

General Concept[edit]

The escidoc core framework must be able to store attributes of users, like the full name or the organizational unit. There are two types of user attributes considered by the core services:

external attributes: attributes delivered via Shibboleth/LDAP
internal attributes: attributes delivered via user-account-handler-interface-call

The user-attributes must be retrievable and updated from the interface of the user-account-handler. The user-attributes are stored as key-value-pairs with key=attribute-name and value=attribute-value.

It must be possible to define groups of users:

based on the value of one or more specific user-attributes
- e.g. to define group of all users belonging to an external orgUnit X plus and have same lastname Y).
- e.g. to define group of all users which have user attribute "Location" to value "Munich"
based on users affiliation to an internal (eSciDoc-managed) organizational unit or children of this organizational unit
- This is a special case, as eSciDoc manages the organizational unit and organizational unit trees.
- To be able to find out the children of the defined organizational-unit, the system has to know the whole tree of organizational-units.
- As we already can define trees of organizational-units in the escidoc-core-framework, we now need to know which user-attribute defines an organizational-unit. Therefore for this attribute we need a reserved name so the system knows that for the group-definition it has to resolve the children of this attribute.

Requirements[edit]

store user-attributes in the escidoc-core-framework.
- user-attributes either come from Shibboleth, LDAP (external) or via the user-account-interface of the escidoc-framework (internal).
retrieve user-attributes
update internal user-attributes
define group via key and value of user-attributes.
define groups of users belonging to an organizational unit or childs of this organizational-unit.

Database Table[edit]

user_attribute:
- contains the user-attributes as key-value
- fields: primkey, user_id, name, value, internal

Interface[edit]

There will be new methods in the user-account-handler-interface for user-attributes:

createAttribute (to create new internal attribute)
retrieveAttributes (retrieves internal + external attributes)
updateAttributes (updates internal attributes)

Questions + Remarks[edit]

Shibboleth has to get configured so it delivers the desired user-attributes to the framework.
With LDAP, all attributes stored with the user are read and written as user-attributes into the framework-internal database.
When defining groups with user-attributes, the name and value of the user-attribute that defines the group has to match the user-attribute delivered by Shibboleth/LDAP.
User-attributes delivered via Shibboleth/LDAP are automatically stored as external attributes in the system whenever the user logs in. If the user formerly logged in via Shibboleth/LDAP and external user-attributes are already stored in the system, these external attributes are deleted and the new attributes are stored.
If the user logs in via the framework-internal database, no user-attributes are written or deleted.
There will be one special user-attribute that has to get handled specially: the org-unit-id. This attribute needs a reserved name so the system knows that for this attribute, the children have to get resolved when authenticating via a group.

XML[edit]

Structure of the user-attributes-xml:

<attribute name="email">michael.hoppe@fiz-karlsruhe.de</attribute>

</attributes>

@@ Line 8: / Line 8: @@
 The user-attributes must be retrievable and updated from the interface of the user-account-handler. The user-attributes are stored as key-value-pairs with key=attribute-name and value=attribute-value.
-It must be possible to define groups with users based on the same user-attributes. It also must be possible to define groups with users having different user-attributes (eg all users belonging to an orgUnit plus all users with the same lastname).
+It must be possible to define groups of users:
-It must be possible to define groups of users belonging to an organizational unit or childs of this organizational-unit. To be able to find out the children of the defined organizational-unit, the system has to know the whole tree of organizational-units. As we already can define trees organizational-units in the escidoc-core-framework, we now need to know which user-attribute defines an organizational-unit. Therefore for this attribute we need a reserved name so the system knows that for the group-definition it has to resolve the children of this attribute.
+* based on the value of one or more specific user-attributes
+** e.g. to define group of all users belonging to an external orgUnit X plus and have same lastname Y).
+** e.g. to define group of all users which have user attribute "Location" to value "Munich"
+*based on users affiliation to an internal (eSciDoc-managed) organizational unit or children of this organizational unit
+**This is a special case, as eSciDoc manages the organizational unit and organizational unit trees.
+**To be able to find out the children of the defined organizational-unit, the system has to know the whole tree of organizational-units.
+**As we already can define trees of organizational-units in the escidoc-core-framework, we now need to know which user-attribute defines an organizational-unit. Therefore for this attribute we need a reserved name so the system knows that for the group-definition it has to resolve the children of this attribute.
 ==Requirements==

Difference between revisions of "ESciDoc User Account Attributes"