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 @@ -74,83 +78,43 @@
| 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 | +
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 +Login
| 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 password column is used, or it can be some external authority, which will be communicated with using some protocol, as @@ -176,14 +140,13 @@ the authority drop-down element at all.
The site-wide systems administrator can configure the +Configuration
| Feature | Status | Description | +
|---|---|---|
| Configuration | ||
| EXT-AUTH-07 | A | Admin pages to control Ext-Auth parameters | +
The site-wide systems administrator can configure the authentication process from a page linked under /acs-admin.
Authorities - ordered list of authorities defined
Account Registration Allowed: Yes/No. Account registration can be disabled altogether.
Registration authority - the authority in which accounts should @@ -194,47 +157,31 @@ and is primarily meant for backwards compatibility with the old OpenACS login process.
The local authority driver is an encapsulation of current -functionality within an driver matching a service contract. The +functionality within a driver matching a service contract. The 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.
Each authority is defined like this:
| Feature | Status | Description | +
|---|---|---|
| create service contract | ||
| 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, +this would be a reference to a service contract implementation.
Authentication Driver configuration settings, e.g. hostname, port, etc., as required by the particular driver. Note that this is per authority, not per driver, i.e., you can have multiple authorities with the same driver but different configuration @@ -248,7 +195,7 @@ 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 -account registration process.
Account Creation Driver configuration settings, e.g. host name, +account registration process.
Account Creation Driver configuration settings, e.g. hostname, port, etc., as required by the particular driver. Note that this is per authority, not per driver, i.e., you can have multiple authorities with the same driver but different configuration @@ -264,53 +211,27 @@ 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.
+authority, be implemented using a service contract.Regardless of the login method, the user needs to have a row in +Users
| 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 users, modify changed, purge deleted) on a regular interval, e.g. every @@ -343,14 +264,13 @@ same person. We'd still have a problem if there was an email conflict between two accounts on the same authority. Hm. I don't think it's worth spending too much time trying to -solve this problem through software.
After having authenticated using the relevant authority driver, +solve this problem through software.
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-31 | ||
| EXT-AUTH-31 | A | Upgrade user data model for ext-auth | +
After having authenticated using the relevant authority driver, we'll look for the username/authority pair in the users table.
If we don't find any, that means that we're either not doing batch synchronizing, or that the user has been added since @@ -367,7 +287,7 @@ Account Registration
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 -account registration through a authority driver.
The account creation service contract implementation will need +account registration through an authority driver.
The account creation service contract implementation will need to tell us which information to ask the user for:
Required Fields: A list of fields which are required.
Optional Fields: A list of fields which are optional.
The fields to choose from are these:
Login pages must be able to be sent over a secure connection +Login Pages Over HTTPS
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-20 | ||
| EXT-AUTH-20 | A | Login over HTTPS | +
Login pages must be able to be sent over a secure connection (https), so your password won't get sent over the wire in cleartext, while leaving the rest of the site non-secure (http). I believe that this requires some (minor) changes to the current @@ -428,14 +347,13 @@ we're messing with this part of the codebase anyway.
I like the idea of having multiple login levels:
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-33 | ||
| EXT-AUTH-33 | A | Untrusted Logins | +
I like the idea of having multiple login levels:
Not logged-in
Untrusted login: We'll show you un-sensitive personal content, but won't let you modify anything or see personal data. A normal login becomes untrusted after a certain amount of @@ -469,20 +387,19 @@ 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
+ad_conn 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.
Currently, OpenACS is unusable in practice without persistent +Non-Persistent Login Work
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-34 | ||
| EXT-AUTH-34 | A | Expire Logins | +
Currently, OpenACS is unusable in practice without persistent login. The login will expire after just a few minutes of inactivity, and you'll get bounced to the login page where you have to enter both email and password again. Unacceptable in @@ -496,12 +413,13 @@ current session handling code.
Instead of redirecting to the login page, auth::require_login +Recommended: Single-Sign-On
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-23 | ||
| EXT-AUTH-23 | Single sign-on | +
Instead of redirecting to the login page, auth::require_login can redirect to an authentication server, which can redirect back 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 @@ -511,14 +429,13 @@
Currently, if you've ever left a permanent login cookie on +Logins
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-22 | ||
| 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 he/she explicitly logs out. You can change your password, you can do anything you want, but unless a logout is requested from that @@ -537,26 +454,24 @@
As an additional security measure, we should email the +Email account owner on password change
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-24 | ||
| EXT-AUTH-24 | A | Email on password change | +
As an additional security measure, we should email the account's email address whenever the password is changed, so that he/she is at least alerted to the fact.
Again, to increase security, we should add password policies, +Optional: Password policy
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-25 | ||
| EXT-AUTH-25 | A | Implement password policy | +
Again, to increase security, we should add password policies, such as passwords needing to be changed after a certain number of days, change on next login (after a new random password has been generated), or requiring that the password satisfies certain @@ -566,14 +481,13 @@
In order to make it easier for people, we've been toying +Without Explicit Authority
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-26 | ||
| 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 = @@ -596,7 +510,7 @@ in the sort order.
The relevant code in user-login.tcl would look like this:
if { ![auth::split_username -username_var username -authority_var authority] } {
- # bounce back to the form with a message saying that the login wasn't valid.
+ # bounce back to the form with a message saying that the login was not valid.
ad_script_abort
}
@@ -605,14 +519,13 @@
While we're touching the session handling code, anyway, it +Optional: Who's Online
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-27 | ||
| EXT-AUTH-27 | B | Who's online list | +
While we're touching the session handling code, anyway, it would be nice to add a feature to show who's currently online, a nice real-time collaboration feature frequently requested by members of the community. This is particularly interesting when @@ -630,36 +543,31 @@
If we want to, we could let subsite administrators configure the +Subsite-level configuration
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-28 | ||
| EXT-AUTH-28 | implement subsite-level config | +
If we want to, we could let subsite administrators configure the login process for that particular subsite. This would probably only entail letting the subsite admin leave out certain authorities defined site-wide, and change the sort order.
I think we should leave this out until we have a use case for it, someone who'd need it.
For completely free-form authentication logic and mechanisms, +the Authentication API itself a service contract
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-32 | ||
| EXT-AUTH-32 | A | Parameters for Service Contract Implementation | +
| EXT-AUTH-35 | A | Make the Authentication API a service contract | +
For completely free-form authentication logic and mechanisms, something like Andrew Grumet's Pluggable Authentication for OACS Draft is interesting. He's proposing a scheme where the entire user interaction is encapsulated in, and left entirely to, a service @@ -673,14 +581,13 @@
Both OKI and OpenACS supports a form of stacking, where you can +Authenticating against multiple servers simultaneously
| Feature | Status | Description | +
|---|---|---|
| EXT-AUTH-36 | ||
| EXT-AUTH-36 | A | Authenticate against multiple servers | +
Both OKI and OpenACS supports a form of stacking, where you can be logged into multiple authorities at the same time. This is useful if, for example, you need to get login tokens such as Kerberos tickets for access to shared resources.
I can see the value in this, but for simplicity's sake, @@ -696,59 +603,28 @@ wait till they're there.
We'll need drivers for:
| Feature | Status | Description | +
|---|---|---|
| Implement specific drivers | ||
| EXT-AUTH-09 | A | Create Auth. drivers for Local Authority | +
| EXT-AUTH-10 | A | Create Acct. Creation driver for Local +Authority | +
| EXT-AUTH-11 | A | Create Auth. driver for PAM | +
| EXT-AUTH-12 | X | Create Acct. Creation +driver for PAM - this functionality is explicitly excluded from +PAM | +
| EXT-AUTH-13 | A | Create Acct. Creation driver for LDAP | +
| EXT-AUTH-14 | A | Create Auth. driver for LDAP | +
We'll need drivers for:
Operating system (Linux/Solaris) PAM: Delegate to the operating system, which can then talk to RADIUS, LDAP, whatever. This is convenient because there'll be plenty of drivers for the OS PAM