Skip to content

Commit

Permalink
- Add interface docs related to how to create authentication policies
Browse files Browse the repository at this point in the history
  and authorization policies to the "Security" narrative chapter.
  • Loading branch information
Chris McDonough committed Jun 19, 2009
1 parent c7b7adb commit 643bd09
Show file tree
Hide file tree
Showing 3 changed files with 68 additions and 6 deletions.
3 changes: 3 additions & 0 deletions CHANGES.txt
Expand Up @@ -172,6 +172,9 @@ Bug Fixes
Documentation
-------------

- Add interface docs related to how to create authentication policies
and authorization policies to the "Security" narrative chapter.

- Added a (fairly sad) "Combining Traversal and URL Dispatch" chapter
to the narrative documentation.

Expand Down
6 changes: 0 additions & 6 deletions TODO.txt
@@ -1,11 +1,5 @@
- path module: use pkg_resources (if feasible, given ZCML)

- audit use of "functools.wraps" (pickling no longer required)

- Docs: add interface docs for IAuthenticationPolicy and
IAuthorizationPolicy, so people who care might be able to write
their own.

- See if we can do something about always looking up ISettings when we
want to see if auto template reload is on (queryUility is a bit
expensive for this task).
Expand Down
65 changes: 65 additions & 0 deletions docs/narr/security.rst
Expand Up @@ -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``.

0 comments on commit 643bd09

Please sign in to comment.