Confirmed users
358
edits
Services/Authentication: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 98: | Line 98: | ||
= Configuration = | = Configuration = | ||
To use the default authentication setup, you need only configure a user backend. In your application config file, create an "auth" | To use the default authentication setup, you need only configure a user backend. In your application config file, create an "auth" section like this: | ||
[auth] | [auth] | ||
| Line 104: | Line 104: | ||
sqluri = sqlite:////tmp/account.db | sqluri = sqlite:////tmp/account.db | ||
By default, the auth framework will interrogate the backend to determine what auth schemes it supports and will load repoze.who plugins for each scheme. | |||
Finer control over the different stages of authentication can be achieved by configuring individual repoze.who plugins. | Finer control over the different stages of authentication can be achieved by configuring individual repoze.who plugins. The configuration syntax matches that of a [http://docs.repoze.org/who/2.0/configuration.html#configuring-repoze-who-via-config-file standalone repoze.who config file] except that it uses dotted section names prefixed with "who". For example the following configuration will authenticate against the user backend using *only* digest authentication. | ||
[who.plugin.digest] | [who.plugin.digest] | ||
| Line 123: | Line 123: | ||
[who.authenticators] | [who.authenticators] | ||
plugins = backend | plugins = backend | ||
| Line 153: | Line 151: | ||
If the client provides valid credentials, the server may include headers in its response to acknowledge the successful authentication. For example, it may set a session cookie. | If the client provides valid credentials, the server may include headers in its response to acknowledge the successful authentication. For example, it may set a session cookie. | ||
= Authentication Schemes = | |||
= Supported Authentication Schemes = | |||
== Basic == | == Basic == | ||
| Line 162: | Line 162: | ||
HTTP Digest Access Auth, as described in [http://www.ietf.org/rfc/rfc2617.txt RFC 2617]. The credentials dict contains all of the parameters from the Authorization header, along with "request-method" and "content-md5". This makes the credentials self-contained so they can be verified by an aribitrary backend that may not have access to the metadata about the request. | HTTP Digest Access Auth, as described in [http://www.ietf.org/rfc/rfc2617.txt RFC 2617]. The credentials dict contains all of the parameters from the Authorization header, along with "request-method" and "content-md5". This makes the credentials self-contained so they can be verified by an aribitrary backend that may not have access to the metadata about the request. | ||
== BrowserID == | == BrowserID == | ||
A custom protocol based on BrowserID/VEP. The credentials dict contains "username" and "assertion", where "assertion" is a valid browserid assertion. | A custom protocol based on BrowserID/VEP. The credentials dict contains "username" and "assertion", where "assertion" is a valid browserid assertion. | ||