| Prev | Chapter�17.�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 @@ -43,11 +44,11 @@ applications talk to the authentication service. There's one and 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 |
|---|---|---|
| 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 |
|---|---|---|
| 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, a authority, and a + authentication drivers implement.
Authentication:
+
Account Management (NO PICTURE YET)
Batch Synchronization (NO PICTURE YET)
| Feature | Status | Description |
|---|---|---|
| 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 |
|---|---|---|
| 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, a 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 +can either be the "local" OpenACS users table, in which case the password column is used, or it can be some external authority, which will be communicated with using some protocol, as implemented by an authentication driver.
Username will be separate from email address. It can be an @@ -83,7 +84,7 @@ other drivers call external functions. The possible functions for each authority are split into several drivers for convenience. One driver handles authentication, one account creation, and one - changing passwords.
| Feature | Status | Description |
|---|---|---|
| EXT-AUTH-16 | A | Create service contract for Authentication |
| EXT-AUTH-17 | A | Create service contract for Acct. Creation |
| EXT-AUTH-29 | A | Create service contract for Passwd Management |
| Feature | Status | Description |
|---|---|---|
| EXT-AUTH-18 | A | Authority configuration data model |
Each authority is defined like this:
Authority pretty-name, e.g. "URZ"
Authentication Driver, e.g. "RADIUS". In practice, this + changing passwords.
| Feature | Status | Description |
|---|---|---|
| EXT-AUTH-16 | A | Create service contract for Authentication |
| EXT-AUTH-17 | A | Create service contract for Acct. Creation |
| EXT-AUTH-29 | A | Create service contract for Passwd Management |
| Feature | Status | Description |
|---|---|---|
| EXT-AUTH-18 | A | Authority configuration data model |
Each authority is defined like this:
Authority pretty-name, e.g. "URZ"
Authentication Driver, e.g. "RADIUS". In practice, this would be a reference to a service contract implementation.
Authentication Driver configuration settings, e.g. host name, port, etc., as required by the particular driver. Note that @@ -95,7 +96,7 @@ trying to use the authentication driver's password management features.
ChangePasswordUrl - a URL to redirect to instead of trying to use the authentication driver's password management - features.
Account Creation Driver, e.g. "RADIUS". In practice, this + features.
Account Creation Driver, e.g. "RADIUS". In practice, this would be a reference to a service contract implementation. The reason we have separate drivers for authentication and account creation is that organizations are likely to have a home-grown @@ -113,7 +114,7 @@ find a mechanism for the driver to tell us which configuration options are available, a way to set these, and a way for the driver 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 +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 |
|---|---|---|
| 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 syncronization |
Regardless of the login method, the user needs to have a row @@ -129,15 +130,15 @@ be remedied by using the real-time solution. The batch job will also require error logging and an admin interface to view logs.
If an email already belongs to some other user, we log it as an error.
A user will always belong to exactly one authority, which can be -either the "local" authority or some other. Thus, the OpenACS user's +either the "local" authority or some other. Thus, the OpenACS user's table will have to be augmented with the following columns:
Authority. Reference to the site-wide authorities list. The authority which can authenticate this user.
Authority-specific username.
Real-time means that the first time the user logs into OpenACS, we'll query the authority that authenticated him for information about this user. That authentication authority will then give us at least first names, last name and email. The pros and cons are the opposite of batch jobs. Using both in combination -is ideal.
Note: One solution to the "two users from different authorities -have the same email" problem above would be to allow users to +is ideal.
Note: One solution to the "two users from different authorities +have the same email" problem above would be to allow users to belong to multiple authorities. Then we would notice that the email already exists, ask the user if he thinks he's the same person, and if so, ask him to prove so by authenticating using the other @@ -154,8 +155,8 @@ create a row in the local users table using that information.
If that doesn't work, we'll tell the user that their account isn't yet available, and the driver will supply a message for us, -which could say "The account should be available tomorrow. If not, -contact X."
If a user doesn't have an account, the site-wide configuration can allow the user to register for one, as defined in the configuration discussed above. This section is about normal @@ -166,7 +167,7 @@ message.
Account status: Is the account ready for use?
User information: first_names, last_name, email, url, password, password_hash, secret_question, secret_answer. The driver only needs to return the columns which were changed or added - through the registration process. Typically, only the "local" + through the registration process. Typically, only the "local" driver will return password and secret question/answer.
After creating the remote account, a local account is created with the information gathered through the form/returned by the driver.
By default, a local account creation implementation is @@ -188,8 +189,8 @@ and at login.
In both cases, it'll be handled by the driver sending automatically sending the email containing a link for the user to verify his account. Then the driver will return an account status -of "closed,temporary", and a message that says ""Check your inbox -and click the link in the email".
OpenACS will have a page which receives the email +of "closed,temporary", and a message that says ""Check your inbox +and click the link in the email".
OpenACS will have a page which receives the email verification, for use by local accounts. Other authorities will have to implement their own page, most likely on the authority's own server.
There are a number of items which touch on external @@ -204,7 +205,7 @@ the user will have to re-enter his/her password in order to gain access to personal data. Untrusted login never expires, unless explicitly done so through either changing password or clicking a - special "expire all logins" link.
Normal login: The user is logged, and has type his + special "expire all logins" link.
Normal login: The user is logged, and has type his password sufficiently recently that we trust the login. All normal operations are allowed. Will degrade to untrusted login after a specified amount of time.
Secure login: The user is logged in over a secure @@ -252,7 +253,7 @@ to a page that logs the user in. This should be very easy to implement.
Alternatively, if you want to combine this with fallback to OpenACS accounts, we would instead present the normal login screen, -but put a button which says "Login using X", where X is the +but put a button which says "Login using X", where X is the redirection-based external authority.
| Feature | Status | Description |
|---|---|---|
| EXT-AUTH-22 | B | rewrite cookie handling |
Currently, if you've ever left a permanent login cookie on someone elses machine, that person will be forever logged in until @@ -281,17 +282,17 @@ numbers, special chars, etc.
It would good to extend the current maximum password length from 10 to at least 32 characters.
| Feature | Status | Description |
|---|---|---|
| EXT-AUTH-26 | B | Login without explicit domain |
In order to make it easier for people, we've been toying with -the idea of a functionality like this:
If the user enters "foobar@ix.urz.uni-heidelberg.de", it - is translated to mean username = "foobar", authority = - "ix.urz.uni-heidelberg.de".
If the user enters "foobar", it's recognized to not +the idea of a functionality like this:
If the user enters "foobar@ix.urz.uni-heidelberg.de", it + is translated to mean username = "foobar", authority = + "ix.urz.uni-heidelberg.de".
If the user enters "foobar", it's recognized to not include any authority, and the default authority of - "ix.urz.uni-heidelberg.de" is used.
If the user enters "foo@bar.com", it's recognized as not + "ix.urz.uni-heidelberg.de" is used.
If the user enters "foo@bar.com", it's recognized as not belonging to any known authority, and as such, it's translated to mean - username = "foo@bar.com", authority = "local".
If this is deemed desirable, a way to implement this would be + username = "foo@bar.com", authority = "local".
If this is deemed desirable, a way to implement this would be through these settings:
Split: A regexp which will split the user's entry into - username and authority parts. For example "^([^@]+)(@[^@]+)?$". An + username and authority parts. For example "^([^@]+)(@[^@]+)?$". An easier to use but less flexible method would be that you simply - specify a certain character to split by, such as "@" or "\". If the + specify a certain character to split by, such as "@" or "\". If the regexp doesn't match, or in the latter case, if there's more than one occurrence of the specified character sequence, the split will fail, signaling that the user's entry was not valid.
Default authority: The default authority will be the first one @@ -314,7 +315,7 @@ which authenticated users have requested pags on the site in the last x minutes (typically about 5), and thus are considered to be currently online. There's nothing more to it. This lets us display -a list of "active users" somewhere on the site, and make their name +a list of "active users" somewhere on the site, and make their name a link to a real-time chat service like Jabber.
We've already made the changes necessary to security-procs.tcl to do this on an earlier project, but haven't quite finished the work and put it back into the tree.