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 +Vision
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 accounts for people. So we want them to be able to create just one account on a central server (e.g. LDAP or RADIUS), and when they log on to OpenACS, an account will automatically be created for them here.
Finally, security is increased with fewer passwords, since users -generally can't remember all those passwords, so they tend to keep -them all the same and never change them.
+generally can't remember all those passwords, so they tend to +keep them all the same and never change them.Transparent: Users don't have to do anything special to get an -account on the local OpenACS system, if they already have an -account on the external authentication server.
Fall-back: Users who don't have an account on the external +
Transparent: Users don't have to do anything special to get +an account on the local OpenACS system, if they already have an +account on the external authentication server.
Fall-back: Users who don't have an account on the external authentication server are still allowed to create a local account on OpenACS. This could be for external students who should have -access to .LRN, but not to the rest of the university's +access to .LRN, but not to the rest of the university's resources.
Authentication Client Only: We want OpenACS to be able to -authenticate by asking some remote authority to verify the user's -username/password combination. The goal is explicitly not (at this point) to have OpenACS act -as an authentication server for other systems, although this could -be easily added later. The goal is also not to devise an infrastructure for +authenticate by asking some remote authority to verify the +user's username/password combination. The goal is explicitly +not (at this point) to have +OpenACS act as an authentication server for other systems, although +this could be easily added later. The goal is also not to devise an infrastructure for letting OpenACS access resources in various other systems on the -user's behalf, such as IMAP, iCalendar, SMB file servers, etc., +user's behalf, such as IMAP, iCalendar, SMB file servers, etc., although this is definitely an interesting use-case.
Easy configuration: We would like people to be able to configure this without having to write code. In particular, we want to build drivers that know how to talk with LDAP, RADIUS, PAM, etc., and -which won't have to be locally modified. Only configuration and +which won't have to be locally modified. Only configuration and policies should change, code should not.
Usability: The solution must be easy to use for end users and -administrators alike. There's frequently a positive feedback effect -between usability and security, because when authentication schemes -have poor usability, users will think up ways to circumvent +administrators alike. There's frequently a positive feedback +effect between usability and security, because when authentication +schemes have poor usability, users will think up ways to circumvent them.
Open and modular: The design should be on the one hand open to add other authentification mechanisms when needed and on the other hand very modular to enable a start with minimal requirements @@ -60,9 +61,9 @@ users.
Authentication Driver: An implementation of the authentication service contract, which talks to an authentication of a certain type, e.g. PAM, RADIUS, LDAP, or Active Directory.
Authentication API: The API through which login pages and -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 +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.
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 -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 email +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 email address, it can look like an email address but not be the name of -an actual email mailbox, or it can be something else entirely.
We're assuming that user information (name, email, etc.) will -either already be in the users table through a batch +an actual email mailbox, or it can be something else entirely.
We're assuming that user information (name, email, etc.) +will either already be in the users table through a batch synchronization job, or that the relevant authentication implementation supports real-time synchronization of user data. -Specifically, if you want remote users who haven't yet logged in to -OpenACS to show up in user searches, you'll have to do the batch -synchronization.
All in all, the login box will be an includeable template and +Specifically, if you want remote users who haven't yet logged +in to OpenACS to show up in user searches, you'll have to do +the batch synchronization.
All in all, the login box will be an includeable template and look like this:
Username: ________ Password: ________ @@ -131,8 +132,8 @@ [Forgot my password] [New user registration] -
If there's only one active authority, we don't display the -authority drop-down element at all.
+If there's only one active authority, we don't display +the authority drop-down element at all.
| 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, +
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 this is per authority, not per driver, i.e., you can have multiple authorities with the same driver but different configuration options.
AuthenticationAllowed - true/false, so you can disable login through some authority without having to delete the authority, and hence also all the users who belong to that authority.
ForgottenPasswordUrl - a URL to redirect to instead of 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 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, +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 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, 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 @@ -202,9 +205,9 @@ 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 local users table. This will, just like any other authority, be -implemetned using a service contract.
+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.Batch job means that we do a synchronization (import new users, modify changed, purge deleted) on a regular interval, e.g. every night. You can also decide to have a monthly full synchronization, -plus daily incremental ones. That's up to you. The advantage is +plus daily incremental ones. That's up to you. The advantage is that you have all users in OpenACS, so when you search for a user, -you'll see all the organization's users, not just those who happen -to have used the OpenACS-based system. The down-side is that it -takes some time for user information to propagate. This can be +you'll see all the organization's users, not just those who +happen to have used the OpenACS-based system. The down-side is that +it takes some time for user information to propagate. This can 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 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 -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 -authority. Thus he'll have just authenticated in two different -authorities, and we can record that this is the 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.
Login pages must be able to be sent over a secure connection -(https), so your password won't get sent over the wire in +(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 session handling code.
Email verification needs to be handled both at registration and -at login.
In both cases, it'll be handled by the driver sending +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 verification, +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.
+their own page, most likely on the authority's own server.There are a number of items which touch on external -authentication and session management. And even though they're not -directly linked to external authentication, I would recommend that -we handle a number of them, either because they're important for -security, or because it makes sense to fix them while we're messing -with this part of the codebase anyway.
| 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 time, and 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 password +
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 +time, and 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 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 connection (HTTPS), potentially even using a special secure password. This would be for sensitive actions, such as credit card transactions.
There are two advantages to this. First, when people's login +
There are two advantages to this. First, when people's login expires, we can ask them to re-enter only their password, and not -both username and password, since we'll still remember who they +both username and password, since we'll still remember who they were the last time their login was valid. This is a much faster operation (the password input field will be focused by default, so you just type your password and hit Return) that typing both username and password, which will make it practical to have your -site configured to expire people's login after e.g. 2, 4, or 8 +site configured to expire people's login after e.g. 2, 4, or 8 hours.
The other advantage is that we can still offer certain functionality to you, even when your login is not trusted. For example, we could let you browse publically available forums, and @@ -374,9 +380,10 @@ setting.
By default, auth::require_login
would bounce to the login page if the user is only logged in at the
untrusted level. Only if you explicitly say auth::require_login -untrusted will we give you
-the user_id of a user who's only logged in in untrusted mode.
Similarly, ad_conn user_id will
+the user_id of a user who's only logged in in untrusted
+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
+in untrusted, and we'll supply another variable, ad_conn untrusted_user_id, which wlll 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 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 -practice.
We should change the default, so a non-persistent login doesn't -expire until you either close your browser, or a few hours have -elapsed. Even if you are constantly active, the login should still -expire after at most x number of hours. We can still make the login -expire after a period of inactivity, but the amount of time should -be configurable and default to something reasonable like an hour or -so.
This will require looking into and changing the design of the +inactivity, and you'll get bounced to the login page where you +have to enter both email and password again. Unacceptable in +practice.
We should change the default, so a non-persistent login +doesn't expire until you either close your browser, or a few +hours have elapsed. Even if you are constantly active, the login +should still expire after at most x number of hours. We can still +make the login expire after a period of inactivity, but the amount +of time should be configurable and default to something reasonable +like an hour or so.
This will require looking into and changing the design of the current session handling code.
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 -redirection-based external authority.
+but put a button which says "Login using X", where X is +the redirection-based external authority.Currently, if you've ever left a permanent login cookie on +
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 particular browser, that browser will be logged in forever.
I want to change our session handling code so that old login cookies can be expired. This would be done automatically whenever you change your password, and we could also offer a link which does -this without changing passwords. It's an important security +this without changing passwords. It's an important security measure.
The implementation is simply to autogenerate some secret token which is stored in the users table, and is also stored in the -cookie somehow. Then, whenever we want to expire all logins, we'll -just regenerate a new secret token, and the other cookies will be -void. Of course, we don't want to incur a DB hit on every request, -so we'll need to cache the secret token, or only check it when -refreshing the session cookie, which, I believe, normally happens -every 10 minutes or so.
+cookie somehow. Then, whenever we want to expire all logins, +we'll just regenerate a new secret token, and the other cookies +will be void. Of course, we don't want to incur a DB hit on +every request, so we'll need to cache the secret token, or only +check it when refreshing the session cookie, which, I believe, +normally happens every 10 minutes or so.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.
+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.
| 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 = -"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 -belonging to any known authority, and as such, it's translated to -mean username = "foo\@bar.com", authority = "local".
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 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 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 through these settings:
Split: A regexp which will split the user's entry into 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 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 +
Split: A regexp which will split the user's entry into +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 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 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 wasn't valid.
ad_script_abort
}
@@ -506,24 +515,27 @@
| Feature | Status | Description | |||
|---|---|---|---|---|---|
| EXT-AUTH-27 | |||||
| EXT-AUTH-27 | B | Who's online list | +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 integrated -with a chat or instant messaging service like Jabber.
What I'm concretely suggesting is that we keep a record of 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 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.
+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 +integrated with a chat or instant messaging service like +Jabber.
What I'm concretely suggesting is that we keep a record of +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 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.
I think we should leave this out until we have a use case for -it, someone who'd need it.
+it, someone who'd need it.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 +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 contract. This certainly opens up more advanced possibilities, such as perhaps smart cards, personal certificates, etc.
I have chosen not to go this route, because I think that most @@ -574,17 +586,17 @@
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, I'm in -favor of keeping this use-case out of the loop until we have -someone with a real requirement who could help us guide +Kerberos tickets for access to shared resources.
I can see the value in this, but for simplicity's sake, +I'm in favor of keeping this use-case out of the loop until we +have someone with a real requirement who could help us guide development.
For now, OpenACS is still more of an integrated suite, it -doesn't access many outside applications. I think it would be +doesn't access many outside applications. I think it would be excellent for OpenACS to do so, e.g. by using an IMAP server to store emails, an iCal server to store calendar appointments, LDAP for user/group data and access control lists, SMB for file storage, -etc. But at the moment, we don't have any users of such things that -are ready. We have some who are on the steps, but let's wait till -they're there.
+etc. But at the moment, we don't have any users of such things +that are ready. We have some who are on the steps, but let's +wait till they're there.| EXT-AUTH-14 | A | Create Auth. driver for LDAP | -
We'll need drivers for:
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 -level, so we don't have to write them all ourselves. The downside -is that we can't do things like account creation, password -management, real-time account synchronization, etc., not supported -by PAM (I'm not entirely sure what is and is not supported).
RADIUS
LDAP
RADIUS
LDAP
RADIUS is a simple username/password-type authentication server.
It also supports sending a challenge to which the user must -respond with the proper answer (e.g. mother's maiden name, or could -be additional password), but we will not support this feature.
A RADIUS client implementation in Python can be found in the +respond with the proper answer (e.g. mother's maiden name, or +could be additional password), but we will not support this +feature.
A RADIUS client implementation in Python can be found in the exUserFolder module for Zope (documentation).
We'd really appreciate feedback on this proposal. Please follow -up at this openacs.org forums thread.
+FeedbackWe'd really appreciate feedback on this proposal. Please +follow up at this openacs.org forums thread.