Difference between revisions of "Pluggable Authentication"

From Davical
Jump to navigationJump to search
(Imported from MoinMoin)
 
m
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Languages|Pluggable Authentication}}
 +
==Status==
  
 
+
In release 0.5.0 a framework has been implemented which allows a hook to provide the authentication and user information.  This does not allow for anything other than providing authentication and user data at this stage.  Notably there is currently no ability for an external source to provide relationship information although any implementation of an authentication hook could take the opportunity to reflect remotely accessible relationships into local DAViCal tables during the authentication phase.
{{TableOfContents}}
 
  
 
==The Goal==
 
==The Goal==
  
The goal of pluggable authentication is to enable the use of external systems as sources of data for authenticating users connecting to RSCDS.  
+
The goal of pluggable authentication is to enable the use of external systems as sources of data for authenticating users connecting to DAViCal.  
  
An other secondary goal would be to support having the external source also provide the relationship information used by RSCDS to control permissions between users.  
+
An other secondary goal would be to support having the external source also provide the relationship information used by DAViCal to control permissions between users.  See [[External Relationship Info|ExternalRelationshipInfo]] for plans around the delegated relationships coming from an external data source.  
  
 
==The Plan==
 
==The Plan==
Line 15: Line 16:
 
==Limitations==
 
==Limitations==
  
At this point the planned system will not meet the secondary goal.  To meet the secondary goal would require some recoding of those functions which calculate permissions to use library functions, which would also need to be written.
+
At this point the planned system will not meet the secondary goal.  To meet the secondary goal would require some recoding of those functions which calculate permissions to use library functions, which would also need to be written.  
 +
 
 +
==A suggested Authentication source==
 +
 
 +
[http://webauth.stanford.edu Webauth] authentication would be good. AIUI it just passes a set of Apache environment variables after the authentication process to specify which user has logged in, so I'd think it'd be fairly easy to implement. Hm, I guess you'd need to dynamically create non-existent users as they were authenticated. But that wouldn't be too hard, would it?
 +
:It has to be done anyway, and is in fact done already in the existing external authentication plugin.
 +
 
 +
The same would allow to authenticate based on an SSL client certificate. The CN could be used as username, and password should never be checked. Something like that.
 +
 
 +
 +
[[Category:Implemented 0.5.0]] [[Category:Roadmap]]

Latest revision as of 16:14, 27 February 2011

Help
Available languages

Status

In release 0.5.0 a framework has been implemented which allows a hook to provide the authentication and user information. This does not allow for anything other than providing authentication and user data at this stage. Notably there is currently no ability for an external source to provide relationship information although any implementation of an authentication hook could take the opportunity to reflect remotely accessible relationships into local DAViCal tables during the authentication phase.

The Goal

The goal of pluggable authentication is to enable the use of external systems as sources of data for authenticating users connecting to DAViCal.

An other secondary goal would be to support having the external source also provide the relationship information used by DAViCal to control permissions between users. See ExternalRelationshipInfo for plans around the delegated relationships coming from an external data source.

The Plan

Implement a hook in the login process.

Limitations

At this point the planned system will not meet the secondary goal. To meet the secondary goal would require some recoding of those functions which calculate permissions to use library functions, which would also need to be written.

A suggested Authentication source

Webauth authentication would be good. AIUI it just passes a set of Apache environment variables after the authentication process to specify which user has logged in, so I'd think it'd be fairly easy to implement. Hm, I guess you'd need to dynamically create non-existent users as they were authenticated. But that wouldn't be too hard, would it?

It has to be done anyway, and is in fact done already in the existing external authentication plugin.

The same would allow to authenticate based on an SSL client certificate. The CN could be used as username, and password should never be checked. Something like that.