| Prev | Chapter 15. Kernel Documentation | Next |
|---|
People have plenty of usernames and passwords already, we +
People have plenty of usernames and passwords already, we don't want them to have yet another. We want people to be able to log in to OpenACS with the same password they use to log in to any other system.
Besides, administrators have better things to do than create @@ -45,7 +45,7 @@ only one implementation of the authentication API, namly the one included in OpenACS Core.
Authentication Driver API: The service contract which authentication drivers implement.
Authentication:
-
Account Management (NO PICTURE YET)
Batch Synchronization (NO PICTURE YET)
| Feature | Status | Description |
|---|---|---|
| New API | ||
| EXT-AUTH-01 | A | Extend Authentication/Acct Status API |
| EXT-AUTH-03 | A | Account Creation API |
| EXT-AUTH-05 | A | Password Management API |
| EXT-AUTH-30 | A | Authority Management API |
| Feature | Status | Description |
|---|---|---|
| Login | ||
| EXT-AUTH-04 | A | Rewrite login, register, and admin pages to use APIs |
| EXT-AUTH-38 | A | ad_form complain feature |
| EXT-AUTH-19 | A | Rewrite password recovery to use API |
| EXT-AUTH-21 | A | Rewrite email verification with API |
| EXT-AUTH-28 | A | Username is email switch |
Users will log in using a username, an authority, and a +
Account Management (NO PICTURE YET)
Batch Synchronization (NO PICTURE YET)
| Feature | Status | Description |
|---|---|---|
| New API | ||
| EXT-AUTH-01 | A | Extend Authentication/Acct Status API |
| EXT-AUTH-03 | A | Account Creation API |
| EXT-AUTH-05 | A | Password Management API |
| EXT-AUTH-30 | A | Authority Management API |
| Feature | Status | Description |
|---|---|---|
| Login | ||
| EXT-AUTH-04 | A | Rewrite login, register, and admin pages to use APIs |
| EXT-AUTH-38 | A | ad_form complain feature |
| EXT-AUTH-19 | A | Rewrite password recovery to use API |
| EXT-AUTH-21 | A | Rewrite email verification with API |
| EXT-AUTH-28 | A | Username is email switch |
Users will log in using a username, an authority, and a password. The authority is the source for user/password verification. OpenACS can be an authority itself.
Each user in OpenACS will belong to exactly one authority, which can either be the "local" OpenACS users table, in which case the @@ -114,7 +114,7 @@ to access these settings.
OpenACS will come pre-configured with one authority, which is the "local" authority, meaning we'll authenticate as normal using the local users table. This will, just like any other authority, be -implemetned using a service contract.
| Feature | Status | Description |
|---|---|---|
| Synchronizing and linking users | ||
| EXT-AUTH-28 | A | Create service contract for Batch Sync. |
| EXT-AUTH-38 | A | Batch User Synchronization API |
| EXT-AUTH-38 | A | IMS Synchronization driver |
| EXT-AUTH-08 | A | Automation of batch Synchronization |
| EXT-AUTH-15 | B | On-demand synchronization |
Regardless of the login method, the user needs to have a row in the OpenACS users table. This can happen through a batch job, in real-time, or both in combination. We use the IMS Enterprise 1.1 specification.
Batch job means that we do a synchronization (import new @@ -230,7 +230,7 @@ mode.
Similarly, ad_conn user_id will continue
to return 0 (not logged-in) when the user is only logged-in
untrusted, and we'll supply another variable, ad_conn
-untrusted_user_id, which wlll be set to the user_id for
+untrusted_user_id, which will be set to the user_id for
all login levels.
This should ensure that we get full access to the new feature, while leaving all current code just as secure as it was before.