| Prev | Next |
Table of Contents
Table of Contents
+
Table of Contents
by Joel Aufrecht
OpenACS docs are written by the named authors, and may be edited
by OpenACS documentation staff.
Index: openacs-4/packages/acs-authentication/www/doc/ext-auth-ldap-install.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-authentication/www/doc/ext-auth-ldap-install.html,v
diff -u -r1.1 -r1.2
--- openacs-4/packages/acs-authentication/www/doc/ext-auth-ldap-install.html 8 Oct 2003 10:08:12 -0000 1.1
+++ openacs-4/packages/acs-authentication/www/doc/ext-auth-ldap-install.html 14 Oct 2003 09:54:26 -0000 1.2
@@ -1 +1 @@
-
...
Installing AOLserver LDAP support.�Forthcoming. (more information)
Install auth-ldap OpenACS service package.�Install auth-ldap and restart the server.
...
Installing AOLserver LDAP support.�Forthcoming. (more information)
Install auth-ldap OpenACS service package.�Install auth-ldap and restart the server.
OpenACS supports PAM authetication via the ns_pam module in AOLserver.
Add PAM support to AOLserver.�OpenACS supports PAM support via the PAM AOLserver +
OpenACS supports PAM authetication via the ns_pam module in AOLserver.
Add PAM support to AOLserver.�OpenACS supports PAM support via the PAM AOLserver module. PAM is system of modular support, and can provide local (unix password), RADIUS, LDAP (more information), and other forms of @@ -34,7 +34,7 @@ which intermediate programs will be used to check permissions. You may need to install software to perform new types of authentication. -
RADIUS in PAM.�
Untar the pam_radius +
RADIUS in PAM.�
Untar the pam_radius tarball and compile and install. (more information)
[root@yourserver root]# cd /usr/local/src/
[root@yourserver src]# tar xf /tmp/pam_radius-1.3.16.tar
@@ -58,4 +58,25 @@
The OpenACS server itself is the "Local Authority," used by
default.Browse to the authentication administration page,
http://yourserver/acs-admin/auth/.
- Create and name an authority (in the sitewide admin UI)
Set Authentication to PAM.
If the PAM module contains a password command, you can set Password Management to PAM. If not, the PAM module cannot change the user's password and you should leave this option Disabled.
Leave Account Registration disabed.
Set Batch sync enabled to Yes. Set GetDocumentImplementation to HTTP GET. Set ProcessDocumentImplementation to IMS Enterprise 1.1. These settings will cause OpenACS to attempt to retrieve via HTTP a list of users in XML format from a location we will specify in a few steps.
Click OK.
On the next page, click Configure on the GetDocument Implementation line.
Enter the IncrementalURL and SnapshotURL. These are the URLs which the external Authority will supply with XML files in IMS Enterprise 1.1 format.
Configure your Authority (RADIUS server, etc) to supply XML files to the URLs IncrementalURL and SnapshotURL
Set Authentication to PAM.
If the PAM module contains a password command, you can set Password Management to PAM. If not, the PAM module cannot change the user's password and you should leave this option Disabled.
Leave Account Registration disabed.
Set Batch sync enabled to Yes. Set GetDocumentImplementation to HTTP GET. Set ProcessDocumentImplementation to IMS Enterprise 1.1. These settings will cause OpenACS to attempt to retrieve via HTTP a list of users in XML format from a location we will specify in a few steps.
Click OK.
On the next page, click Configure on the GetDocument Implementation line.
Enter the IncrementalURL and SnapshotURL. These are the URLs which the external Authority will supply with XML files in IMS Enterprise 1.1 format.
Configure your Authority (RADIUS server, etc) to supply XML files to the URLs IncrementalURL and SnapshotURL
+<enterprise> + <person recstatus = "1"> added person + <sourcedid> + <id>[username]</id> + </sourcedid> + <name> + <family>[last_name]</family> + <given>[first_names]</given> + </name> + <email>[email]</email> + <url>[homepage_url]</url> + </person> + <person recstatus = "2"> modified person + ... + </person> + <person recstatus = "3"> deleted person + <sourcedid> + <id>LL1</id> only requires username + </sourcedid> + </person> +</enterprise>
(More information: Section�, “IMS Sync driver design”, The IMS 1.1 spec)
We need examples of how the communication would be done from our +clients.
The "GetDocument" communications service contract could be a +generic system-wide service contract.
We might need a source/ID column in the users table to identify +where they're imported from for doing updates, particularly if +importing from multiple sources (or when some users are local.)
We will parse a document in the IMS Enterprise + Specification format (example + XML document), and translate it into calls to the batch user + sync API.
The document will contain either the complete user listitemst (IMS: + "snapshot"), or an incremental user listitemst (IMS: "Event Driven" -- + contains only adds, edits, and deletes). You could for example do a + complete transfer once a month, and incrementals every night. The + invocation should decide which type is returned.
The design should favor interoperability, reliability and robustness.
+<enterprise> + + <properties> + <datasource>Dunelm Services Limited</datasource> + <target>Telecommunications LMS</target> + <type>DATABASE UPDATE</type> + + <datetime>2001-08-08</datetime> + </properties> + <person recstatus = "1"> + <comments>Add a new Person record.</comments> + <sourcedid> + + <source>Dunelm Services Limited</source> + <id>CK1</id> + </sourcedid> + <name> + <fn>Clark Kent</fn> + + <sort>Kent, C</sort> + <nickname>Superman</nickname> + </name> + <demographics> + <gender>2</gender> + + </demographics> + <adr> + <extadd>The Daily Planet</extadd> + <locality>Metropolis</locality> + <country>USA</country> + + </adr> + </person> + <person recstatus = "2"> + <comments>Update a previously created record.</comments> + <sourcedid> + + <source>Dunelm Services Limited</source> + <id>CS1</id> + </sourcedid> + <name> + <fn>Colin Smythe</fn> + + <sort>Smythe, C</sort> + <nickname>Colin</nickname> + <n> + <family>Smythe</family> + + <given>Colin</given> + <other>Manfred</other> + <other>Wingarde</other> + <prefix>Dr.</prefix> + + <suffix>C.Eng</suffix> + <partname partnametype = "Initials">C.M.W.</partname> + </n> + </name> + <demographics> + + <gender>2</gender> + <bday>1958-02-18</bday> + <disability>None.</disability> + </demographics> + + <email>colin@dunelm.com</email> + <url>http://www.dunelm.com</url> + <tel teltype = "Mobile">4477932335019</tel> + <adr> + + <extadd>Dunelm Services Limited</extadd> + <street>34 Acorn Drive</street> + <street>Stannington</street> + <locality> Sheffield</locality> + + <region>S.Yorks</region> + <pcode>S7 6WA</pcode> + <country>UK</country> + </adr> + + <photo imgtype = "gif"> + <extref>http://www.dunelm.com/staff/colin2.gif</extref> + </photo> + <institutionrole primaryrole = "No" institutionroletype = "Alumni"/> + <datasource>dunelm:colinsmythe:1</datasource> + + </person> + <person recstatus = "3"> + <comments>Delete this record.</comments> + <sourcedid> + <source>Dunelm Services Limited</source> + + <id>LL1</id> + </sourcedid> + <name> + <fn>Lois Lane</fn> + <sort>Lane, L</sort> + + </name> + </person> +</enterprise> +
Above would get translated into calls to the batch sync API as +follows:
+for { ... loop over persons in the document ... } {
+ auth::batch::transaction \
+ -job_id $job_id \
+ -operation [ad_decode $recstatus 2 "update" 3 "delete" "insert"] \
+ -authority_id $authority_id \
+ -username { $userid if present, otherwise $sourcedid.id } \
+ -first_names { $name.given if present, otherwise all except last part of $name.fn } \
+ -last_name { $name.family if present, otherwise last part of $name.fn } \
+ -email { $person.email ; we require this, even though the specification does not } \
+ -url { $url, if present } \
+ -portrait_url { $photo.imgtype/$photo.extref -- grab photo, store in DB }
+ }
+}
+Mandatory fields which we can rely on are:
sourcedid: ID as defined by the source system. Used for username.
name.fn (formatted name). Used for first_names, last_name
Note that we require 'email' attribute, but the IMS Enterprise +spec does not. Hence, unless we change our data model to allow users +without an email address, we will have to throw an error.
Here's how we map IMS enterprise to OpenACS tables.
username:
<userid> ... </userid> if present.
<sourcedid><id> ... </id></sourcedid> otherwise
first_names:
<name><given> ...</given></name> if present.
<name><fn> ... ...</fn></name> otherwise
last_name:
<name><family> ...</family></name> if present.
<name><fn>... ...</fn></name> otherwise
email:
<email> ...</email> if present.
Blank/unchanged if not.
url:
<url> ...</url> if present.
Blank/unchanged if not.
portrait:
+ <photo imgtype="gif"><extref>...</extref></photo> if present: + HTTP GET the photo, insert it into the system. (Do we do this, + then, with all users when doing a snapshot update?) +
Consolidation + before the leap; IMS Enterprise 1.1: This article says that IMS + Enterprise 1.1 (current version) does not address the communication + model, which is critically missing for real seamless + interoperability. IMS Enterprise 2.0 will address this, but + Blackboard, who's influential in the IMS committee, is adopting + OKI's programming interrfaces for this.
Table of Contents