Difference between revisions of "ESciDoc User Account Attributes"

From MPDLMediaWiki
Jump to navigation Jump to search
m
 
(13 intermediate revisions by 2 users not shown)
Line 5: Line 5:
*external attributes: attributes delivered via Shibboleth/LDAP  
*external attributes: attributes delivered via Shibboleth/LDAP  
*internal attributes: attributes delivered via user-account-handler-interface-call  
*internal attributes: attributes delivered via user-account-handler-interface-call  
'''Important:''' a user attribute may have several values e.g. attribute "Location" may have both values of "Munich" and "Karlsruhe"


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.
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.
Line 14: Line 16:
** e.g. to define group of all users which have user attribute "Location" to value "Munich"
** 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
*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.
**This is a special case, as eSciDoc manages the organizational unit data as well internally
**To be able to find out the children of the defined organizational-unit, the system has to know the whole tree of organizational-units.
***for this purpose we need a reserved name for a user attribute based on which the system would know how to resolve OU-based group-definition (for the OU and OU children).
**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.
*based on users affiliation to an external (non-eSciDoc-managed) organizational unit or children of this organizational unit
**these user attributes are treated as any other user attribute as their control is out of eSciDoc.


==Requirements==
==Requirements==
Line 24: Line 27:
*update internal user-attributes
*update internal user-attributes
*define group via key and value of 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.
*define groups of users belonging to an organizational unit or children of this organizational-unit.
*define groups based on combination of organizational unit and user-attribute


==Database Table==
==Database Table==
Line 30: Line 34:
**contains the user-attributes as key-value
**contains the user-attributes as key-value
**fields: primkey, user_id, name, value, internal
**fields: primkey, user_id, name, value, internal
:would here add also a timestamp of attribute creation and timestamp of last attribute modification


==Interface==
==Interface==
There will be new methods in the user-account-handler-interface for user-attributes:
There will be new methods in the user-account-handler-interface for user-attributes:
*createAttribute (to create new internal attribute)
*createAttribute(userId, attributeXml) to create a new internal attribute
*retrieveAttributes (retrieves internal + external attributes)
*deleteAttribute(userId, attributeId) to delete an internal attribute
*updateAttributes (updates internal attributes)
*retrieveAttribute(userId, attributeId) to retrieve an attribute by it's id
*retrieveAttributes(userId) to retrieve all internal + external attributes
*retrieveNamedAttributes(userId, attributeName) to retrieve all internal and external attributes with that name
*updateAttribute(userId, attributeId, attributeXml) to update an internal attribute


==Questions + Remarks==
==Questions + Remarks==
*Shibboleth has to get configured so it delivers the desired user-attributes to the framework.
*Shibboleth has to get configured to deliver the desired user-attributes to the core-service. These attributes are transferred/updated with each authentication of the user. These are external attributes.
*With LDAP, all attributes stored with the user are read and written as user-attributes into the framework-internal database.
*With LDAP, all attributes stored with the user are read and written as external user-attributes into the core-service 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.
*When defining groups based on 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.
*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.
**probably here attributes should not be deleted, but updated with the new value, and new attributes should be created.
*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.
**the reasons: by deletion, at some point one may have attribute-based group definition where no attributes existed before, and this will open new more discrepancy, also it is better controllable and testable, i.e. last user log-in etc. --[[User:Natasab|Natasa]] 14:58, 26 February 2009 (UTC)
**imho an attribute should be deleted only in case when it is no longer delivered at all via Shib/LDAP, in all other cases, value of the attribute should be updated --[[User:Natasab|Natasa]] 14:58, 26 February 2009 (UTC)
 
 
*If the user logs in via the core-service-internal authentication mechanism, 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 also should be resolved when authenticating via a group.
 
=== Questions ===
*is it possible for same instance of core-service to have two authentication mechanisms in place at the same time (e.g. both local and LDAP)?


==XML==
==XML==
Line 54: Line 70:
</attributes>
</attributes>


[[Category:eSciDoc]]
 
:should not this XML also contain the type of the attribute (internal/external)? --[[User:Natasab|Natasa]] 14:51, 26 February 2009 (UTC)
 
[[Category:eSciDoc|User Account Attributes]]

Latest revision as of 09:43, 7 January 2011

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

Important: a user attribute may have several values e.g. attribute "Location" may have both values of "Munich" and "Karlsruhe"

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 data as well internally
      • for this purpose we need a reserved name for a user attribute based on which the system would know how to resolve OU-based group-definition (for the OU and OU children).
  • based on users affiliation to an external (non-eSciDoc-managed) organizational unit or children of this organizational unit
    • these user attributes are treated as any other user attribute as their control is out of eSciDoc.

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 children of this organizational-unit.
  • define groups based on combination of organizational unit and user-attribute

Database Table[edit]

  • user_attribute:
    • contains the user-attributes as key-value
    • fields: primkey, user_id, name, value, internal
would here add also a timestamp of attribute creation and timestamp of last attribute modification

Interface[edit]

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

  • createAttribute(userId, attributeXml) to create a new internal attribute
  • deleteAttribute(userId, attributeId) to delete an internal attribute
  • retrieveAttribute(userId, attributeId) to retrieve an attribute by it's id
  • retrieveAttributes(userId) to retrieve all internal + external attributes
  • retrieveNamedAttributes(userId, attributeName) to retrieve all internal and external attributes with that name
  • updateAttribute(userId, attributeId, attributeXml) to update an internal attribute

Questions + Remarks[edit]

  • Shibboleth has to get configured to deliver the desired user-attributes to the core-service. These attributes are transferred/updated with each authentication of the user. These are external attributes.
  • With LDAP, all attributes stored with the user are read and written as external user-attributes into the core-service database.
  • When defining groups based on 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.
    • probably here attributes should not be deleted, but updated with the new value, and new attributes should be created.
    • the reasons: by deletion, at some point one may have attribute-based group definition where no attributes existed before, and this will open new more discrepancy, also it is better controllable and testable, i.e. last user log-in etc. --Natasa 14:58, 26 February 2009 (UTC)
    • imho an attribute should be deleted only in case when it is no longer delivered at all via Shib/LDAP, in all other cases, value of the attribute should be updated --Natasa 14:58, 26 February 2009 (UTC)


  • If the user logs in via the core-service-internal authentication mechanism, 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 also should be resolved when authenticating via a group.

Questions[edit]

  • is it possible for same instance of core-service to have two authentication mechanisms in place at the same time (e.g. both local and LDAP)?

XML[edit]

Structure of the user-attributes-xml:

<attributes user-objid="escidoc:user42">

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

</attributes>


should not this XML also contain the type of the attribute (internal/external)? --Natasa 14:51, 26 February 2009 (UTC)