- Status Closed
- Percent Complete
- Task Type Feature Request
- Category Backend / Core
- Assigned To No-one
- Operating System All
- Severity Low
- Priority Very Low
- Reported Version Stable
- Due in Version 2.35
-
Due Date
Undecided
- Votes
- Private
FS#119 - Single sign on
It would be great if PO could work together with the web server (assuming Apache here) to do authentication and authorization.
Apache allows for user names and passwords to be stored in a database, including PostgreSQL. For details see http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html
Now, if we could make apache use a table in the PO database, or alternatively let PO use a table in an Apache authentication database, the authentication with apache would imply a login into PO. So if I would want to restrict parts of my website I can use Apache's authentication mechanism, and once in, I am immediately logged into PO. Thus having a single sign on policy.
Of course we could couple the user name with which the user logged into Apache as the basis for single sign on into PO, so having a different list of users for PO than for the whole website, but from an administrative point of view it seems to me to be more useful to have it in a single place.
Next, users can be assigned to groups. Thus a user that is authenticated for the website does not necessarily have to be a user of PO. Just make a PO group and any user that gets added to PO will be added to this group. Now, when we update a password in PO it will be automatically updated for the whole site.
The next thing is to get this authentication to work for other php applications as well. Maybe there is a standard solution for this available already.
2007-09-24 16:16
Reason for closing: Implemented
Additional comments about closing: The framework is now complete, including the "auto-registration" of externally-authenticated users. The only "authentication method" currently implemented is the existing PO-DB system, but adding external mechanisms is now possible.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
This sort of thing is one of the motivations for the session_id rewrite. Once that's all happening in one place, it's far, far easier to switch out session management and authentication mechanisms. See the related tickets (#111, #93).
I definately want to split apart the user info / authentication / session stuff, which is currently in the same table..
The basic problem is that we have our own per-user account info that has to be created and/or maintained independently of where the authentication takes place.
There is an additional problem -- what about the case where an external entity also controls whether or not the user can use the photo organizer? The base http auth model doesn't handle this.
Discounting this, it's a pretty straightforward feature to implement now. The login page tests to see if the http auth tokens are valid, and if they are, create an account for them on the PO site if necessary, and otherwise the usual rules apply.
Another wrinkle here is that we'd need to continue checking the http auth tokens on each request, not just "login", because the instant they lose authentication, we need to revoke their access to the site.
r1625 has most of the necessary work implemented to support this.
All that remains is finishing the code that automagically "registers" authenticated users.