summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorChris McDonough <chrism@agendaless.com>2009-06-19 12:27:15 +0000
committerChris McDonough <chrism@agendaless.com>2009-06-19 12:27:15 +0000
commit643bd0903f3fa64307f22f5173fefbe0871603fc (patch)
treed38a3ebaf8050dde8fda46dba55eeebe905f9a9e /docs
parentc7b7adbaed26c9d6b2f4f72754da8615f5aa579c (diff)
downloadpyramid-643bd0903f3fa64307f22f5173fefbe0871603fc.tar.gz
pyramid-643bd0903f3fa64307f22f5173fefbe0871603fc.tar.bz2
pyramid-643bd0903f3fa64307f22f5173fefbe0871603fc.zip
- Add interface docs related to how to create authentication policies
and authorization policies to the "Security" narrative chapter.
Diffstat (limited to 'docs')
-rw-r--r--docs/narr/security.rst65
1 files changed, 65 insertions, 0 deletions
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 52178fa26..0a97452ca 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -388,3 +388,68 @@ these objects will have a ``msg`` attribute, which is a string
indicating why permission was denied or allowed. Introspecting this
information in the debugger or via print statements when a
``has_permission`` fails is often useful.
+
+Creating Your Own Authentication Policy
+---------------------------------------
+
+:mod:`repoze.bfg` ships with a number of useful out-of-the-box
+security policies (see :ref:`authentication_policies_api_section`).
+However, creating your own authentication policy is often necessary
+when you want to control the "horizontal and vertical" of how your
+users authenticate. Doing so is matter of creating an instance of
+something that implements the following interface:
+
+.. code-block:: python
+
+ class AuthenticationPolicy(object):
+ """ An object representing a BFG authentication policy. """
+ def authenticated_userid(self, request):
+ """ Return the authenticated userid or ``None`` if no
+ authenticated userid can be found. """
+
+ def effective_principals(self, request):
+ """ Return a sequence representing the effective principals
+ including the userid and any groups belonged to by the current
+ user, including 'system' groups such as Everyone and
+ Authenticated. """
+
+ def remember(self, request, principal, **kw):
+ """ Return a set of headers suitable for 'remembering' the
+ principal named ``principal`` when set in a response. An
+ individual authentication policy and its consumers can decide
+ on the composition and meaning of **kw. """
+
+ def forget(self, request):
+ """ Return a set of headers suitable for 'forgetting' the
+ current user on subsequent requests. """
+
+Pass the object you create into the ``repoze.bfg.router.make_app``
+function as the ``authentication_policy`` argument at application
+startup time (usually within a ``run.py`` module).
+
+Creating Your Own Authorization Policy
+--------------------------------------
+
+An authentiction policy the policy that allows or denies access after
+a user is authenticated. By default, :mod:`repoze.bfg` will use the
+``repoze.bfg.authorization.ACLAuthorizationPolicy`` if an
+authentication policy is activated. Creating and using your own
+authorization policy is a matter of creating an instance of an object
+that implements the following interface:
+
+.. code-block:: python
+
+ class IAuthorizationPolicy(object):
+ """ A adapter on context """
+ def permits(self, context, principals, permission):
+ """ Return True if any of the principals is allowed the
+ permission in the current context, else return False """
+
+ def principals_allowed_by_permission(self, context, permission):
+ """ Return a set of principal identifiers allowed by the
+ permission """
+
+Pass the object you create into the ``repoze.bfg.router.make_app``
+function as the ``authorization_policy`` argument at application
+startup time (usually within a ``run.py`` module). You must also pass
+an ``authentication_policy`` if you pass an ``authorization_policy``.