fp-wiki>ImportUser (Imported from MoinMoin) |
m (Categorize) |
||
(One intermediate revision by one other user not shown) | |||
Line 273: | Line 273: | ||
I'm a little less sure on the making groups a member of other groups issue. | I'm a little less sure on the making groups a member of other groups issue. | ||
[[Category:Infrastructure]] |
Latest revision as of 21:55, 8 January 2010
This is a page to cover the current schema and how to implement it and the modifications that are required for the new account system in LDAP or in SQL
Current Schema
person id, username, email, human_name, gpg_keyid, ssh_key, password, comments, postal_address, telephone, facsimile, affiliation, creation, approval_status, internal_comments, wiki_prefs, ircnick
project_group id, name, owner_id, group_type, needs_sponsor, user_can_remove, prerequisite_id, joinmsg
role person_id, project_group_id, role_type, role_domain, role_status, internal_comments, sponsor_id (Points to a person), creation (TIMESTAMP), approval (TIMESTAMP)
Problems with the current schema
- Cannot make groups members of a group
- Cannot have multiple email addresses
LDAP
A new schema must be made, however, most information can be mapped from existing schemas.
Thanks to http://directoryproject.isc.ucsb.edu/schema/inetorgperson.html for some of the info.
The new fedoraPerson schema. inetOrgPerson is a superior.
Person Schema
Required Attributes
Attribute name | Description | Mapping from DB |
objectClass | Defines the object classes for the entry. | |
cn (commonName) | The person’s common name. | human name |
sn (surname) | The person’s surname, or last name. | human name |
The person's email address |
Custom Required Attributes
fedoraPersonSshKey | Person's public ssh key | ssh_key |
fedoraPersonCreationDate | the creation date of the person object | creation |
Allowed Attributes
Attribute name | Description | Mapping from DB |
description | Text description of the person. | internal comments |
fax (facsimileTelephoneNumber) | The person’s fax number. | facsimile |
givenName | The person’s given, or first, name. | human name |
The person’s email address. | ||
o (organizationName) | Organization to which the person belongs. | affiliation |
ou (organizationUnitName) | Organizational unit to which the person belongs. | don't know yet |
postalAddress | The person’s mailing address. | postal address |
telephoneNumber | The person’s telephone number. | telephone |
userPassword | Password with which the entry can bind to the directory. | password |
Custom Allowed Attributes
Attribute name | Description | Mapping from DB |
fedoraPersonApprovalStatus | The person's approval status | approval_status |
fedoraPersonIrcNick | The person's irc nick | ircnick |
fedoraPersonBugzillaMail | The bugzilla email for the person | none |
fedoraPersonKeyId | Stores a user’s certificate in cleartext. | gpg_key id |
Attributes Not Carried over from the Original Person Schema
wikiprefs
Group Schema
Required Attributes
Attribute name | Description | Mapping from DB |
cn | The name of the group | name |
fedoraGroupOwner | owner of the group | owner_id |
Allowed Attributes
Attribute name | Description | Mapping from DB |
fedoraGroupJoinMsg | Message given upon joining a group | joinmsg |
fedoraGroupUserCanRemove | boolean indicating if a user can remove the group | user_can_remove |
fedoraGroupType | Type of group eg. cvs, bugzilla, shell | group_type |
fedoraGroupNeedsSponsor | Boolean indicating if the group needs a sponsor | needs_sponsor |
fedoraGroupRequires | Prerequisites of this Group | prerequisite_id |
Role Schema
Required Attributes
Attribute name | Description | Mapping from DB |
cn | The name of the role | project_group_id role_type person_id |
Allowed Attributes
Attribute name | Description | Mapping from DB |
fedoraRoleType | the type of role. eg user, administrator | role_type |
fedoraRoleDomain | The domain of the role | role_domain ( this is always blank in the current db ) |
fedoraRoleApprovalStatus | the approval status of a role | approval_status |
fedoraRoleSponsor | the sponsor for the role | sponsor_id (this was a forign key ) |
fedoraRoleCreationDate | The creation date of the role | creation |
fedoraRoleApprovalDate | The approval date of the role | approval |
Attributes Not Carried over from the Original Role Schema
internal_comments
Proposed LDAP schema
LDAP is good at representing properties of an object, but it's not good at representing relationships between objects. This LDAP schema tries to implement the features we have in the present account system with an LDAP directory:
dc=fedoraproject,dc=org (standard schema) |- ou=People (organisationalUnit) | |- uid=abompard (inetOrgPerson + a few added attributes) | | |- cn=group1 (custom: fedoraRole) | | |- cn=group2 (custom: fedoraRole) | | <code>- cn=group3 (custom: fedoraRole) | <code>- uid=lyz (inetOrgPerson + a few added attributes) | <code>- cn=group1 (custom: fedoraRole) | <code>- ou=Groups (organisationalUnit) |- cn=group1 (custom: fedoraGroup) <code>- cn=group2 (custom: fedoraGroup)
etc, you get the idea. The custom objectClasses would be where the magic is.
The fedoraMembership objectClass would basically be a mapping of the role table. It would be able to contain the following attributes:
- cn (the group name)
- role_type
- role_domain
- role_status
- internal_comments
- sponsor (points to the sponsor's DN)
- creation (date)
- approval (date)
I think it should also have an uid
attribute where the uid of the person would be repeated. It duplicates information but it makes it much easier to list the members of a group. With the uid it's just a matter of searching for (&(objectClass=fedoraMembership)(cn=group1))
and retrieving only the uid
attribute, while without it you have to do the same search and to go up one level for each entry. I think many applications can be configured for group listing by giving a search string, but can't do anything more complicated.
The bad side is obviously that it duplicates information.
To get the uid
attribute we can have the fedoraMembership objectClass heritate of the uidObject objectClass, which has just this attribute, or add it specifically.
My opinion is that the duplication is a necessary evil here, and can be masked by the interface we'll write to avoid user mistake.
The fedoraGroup objectClass would basically be a mapping of the project_group table. It would contain the following attributes:
- owner (the owner's DN)
- group_type
- needs_sponsor
- user_can_remove (will be handled by ACLs, but we need to clue the interface about it)
- prerequisite_id (no idea what that is, so maybe not)
- joinmsg
It would not be a groupOfNames. The membership information is stored as described earlier. It would more be information about the group itself.
This structure has the following benefits:
- we're close to the inetOrgPerson objectClass, which many apps expect
- it is close to what we have now (basically a mapping) so it won't be hard to adapt it
- we can add fields to the schema in the future if we need more info about the relationship between the user and the group
- when a user is removed, all its memberships are removed at the same time since they're sub-entries, so no stale pointers.
- we don't hardcode the available role_types (some of my earler proposals did this)
I see the following shortcomings:
- having information about the user in a subentry of this user looks strange (inhabitual) in an LDAP directory.
- it duplicates some information
- maybe mapping too closely the workings of a relational database to a hierarchical directory will cause problems in the future
About the two problems with the current schema:
- "Cannot have multiple email addresses": LDAP solves it by itself
- "Cannot make groups members of a group": I don't have a perfect solution for that right now. We could add a fedoraMembership sub-entry to the fedoraGroup entries, that would work and be consistent, but the
uid
attribute in the fedoraMembership sub-entry would be empty then (since it doesn't apply to a user), it would have to have acn
attribute instead, so we can't make theuid
attribute mandatory. A solution to this would be to make a generic fedoraMembership objectClass and two fedoraUserMembership and fedoraGroupMembership objectClasses which would inherit it and bring the user or group specific attributes.
Any comment on fedora-infrastructure-list would be very appreciated.
Other Attributes to Add
User
- uid -- For other databases to use as a reference to the person
- system account -- boolean, whether the account is for a real person or for a system account (which shouldn't be able to login)
group
- gid -- For other databases to use as a reference to the group.
- email address -- (Can be a mailing list that most members of the group are in or an alias that sends to everyone in the group)
SQL
The current schema is ok, but we need to adress the issues. To fix the multiple email address issue a table can be made email person_id email_address The primary key would be the combination of the id and address.
I'm a little less sure on the making groups a member of other groups issue.