Commit f1439128 authored by Constantinos Venetsanopoulos's avatar Constantinos Venetsanopoulos
Browse files

docs: Update index page & Astakos related docs

 * Update index page
 * Rewrite the Astakos description in astakos.rst
 * Move useful info from astakos.rst to the Admin Guide
 * Remove obsolete info from astakos.rst
 * Refactor the Admin Guide's Astakos section
parent 38471c3a
......@@ -26,22 +26,22 @@ Identity Service (Astakos)
==========================
Overview
--------
Authentication methods
~~~~~~~~~~~~~~~~~~~~~~
----------------------
Local Authentication
````````````````````
Astakos supports multiple authentication methods:
LDAP Authentication
```````````````````
* local username/password
* LDAP / Active Directory
* SAML 2.0 (Shibboleth) federated logins
* Google
* Twitter
* LinkedIn
.. _shibboleth-auth:
Shibboleth Authentication
`````````````````````````
~~~~~~~~~~~~~~~~~~~~~~~~~
Astakos can delegate user authentication to a Shibboleth federation.
......@@ -90,7 +90,7 @@ Finally, add 'shibboleth' in ``ASTAKOS_IM_MODULES`` list. The variable resides
inside the file ``/etc/synnefo/20-snf-astakos-app-settings.conf``
Twitter Authentication
```````````````````````
~~~~~~~~~~~~~~~~~~~~~~
To enable twitter authentication while signed in under a Twitter account,
visit dev.twitter.com/apps.
......@@ -104,9 +104,8 @@ Fill the necessary information and for callback URL give::
Finally, add 'twitter' in ``ASTAKOS_IM_MODULES`` list. The variable resides
inside the file ``/etc/synnefo/20-snf-astakos-app-settings.conf``
Google Authentication
`````````````````````
~~~~~~~~~~~~~~~~~~~~~
To enable google authentication while signed in under a Google account,
visit https://code.google.com/apis/console/.
......@@ -123,17 +122,6 @@ Fill the necessary information and for callback URL give::
Finally, add 'google' in ``ASTAKOS_IM_MODULES`` list. The variable resides
inside the file ``/etc/synnefo/20-snf-astakos-app-settings.conf``
Architecture
------------
Prereqs
-------
Installation
------------
Configuration
-------------
Working with Astakos
--------------------
......@@ -161,11 +149,9 @@ command:
email : user@synnefo.org
....
Based on how your configuration of `astakos-app`, there are several ways for a
user to get activated and be able to login. We discuss the user activation
flow in the following section.
Based on the `astakos-app` configuration, there are several ways for a user to
get verified and activated in order to be able to login. We discuss the user
verification and activation flow in the following section.
User activation flow
````````````````````
......@@ -175,7 +161,6 @@ is submited successfully a user entry is created in astakos database. That entry
is passed through the astakos activation backend which handles whether the user
should be automatically verified and activated.
Email verification
``````````````````
......@@ -196,15 +181,14 @@ At this stage:
* administrator may also enforce a user to get verified using the
``snf-manage user-modify --verify <userid>`` command.
Account activation
``````````````````
Once user gets verified it is time for astakos to decide whether or not to
Once the user gets verified, it is time for Astakos to decide whether or not to
proceed through user activation process. If ``ASTAKOS_MODERATION_ENABLED``
setting is set to ``False`` (default value) user gets activated automatically.
In case the moderation is enabled astakos may still automatically activate the
In case the moderation is enabled Astakos may still automatically activate the
user in the following cases:
* User email matches any of the regular expressions defined in
......@@ -213,11 +197,12 @@ user in the following cases:
activation is enabled (see
:ref:`authentication methods policies <auth_methods_policies>`).
If all of the above fail to trigger automatic activation, an email is sent
to the persons listed in ``HELPDESK``, ``MANAGERS`` and ``ADMINS`` settings,
notifing that there is a new user pending for moderation and that it's
up to the administrator to decide if the user should be activated, using the
``user-modify`` command.
If all of the above fail to trigger automatic activation, an email is sent to
the persons listed in ``HELPDESK``, ``MANAGERS`` and ``ADMINS`` settings,
notifing that there is a new user pending for moderation and that it's up to
the administrator to decide if the user should be activated. The UI also shows
a corresponding 'pending moderation' message to the user. The administrator can
activate a user using the ``snf-manage user-modify`` command:
.. code-block:: console
......@@ -227,11 +212,10 @@ up to the administrator to decide if the user should be activated, using the
# command to reject a pending user
$ snf-manage user-modify --reject --reject-reason="spammer" <userid>
Once activation process finish, a greeting message is sent to the user email
address and a notification for the activation to the persons listed in
``HELPDESK``, ``MANAGERS`` and ``ADMINS`` settings. Once activated the user is
able to login and access the synnefo services.
Once the activation process finishes, a greeting message is sent to the user
email address and a notification for the activation to the persons listed in
``HELPDESK``, ``MANAGERS`` and ``ADMINS`` settings. Once activated the user is
able to login and access the Synnefo services.
Additional authentication methods
`````````````````````````````````
......@@ -293,6 +277,20 @@ locally signed up users under moderation you can apply the following settings.
ASTAKOS_AUTH_PROVIDER_SHIBBOLETH_AUTOMODERATE_POLICY = True
ASTAKOS_AUTH_PROVIDER_SHIBBOLETH_REMOVE_POLICY = False
User login
~~~~~~~~~~
During the logging procedure, the user is authenticated by the respective
identity provider.
If ``ASTAKOS_RECAPTCHA_ENABLED`` is set and the user fails several times
(``ASTAKOS_RATELIMIT_RETRIES_ALLOWED`` setting) to provide the correct
credentials for a local account, he/she is then prompted to solve a captcha
challenge.
Upon success, the system renews the token (if it has expired), logins the user
and sets the cookie, before redirecting the user to the ``next`` parameter
value.
Setting quota limits
~~~~~~~~~~~~~~~~~~~~
......@@ -377,9 +375,9 @@ html file that will contain your terms. For example, create the file
.. code-block:: console
<h1>~okeanos terms</h1>
<h1>My cloud service terms</h1>
These are the example terms for ~okeanos
These are the example terms for my cloud service
Then, add those terms-of-use with the snf-manage command:
......@@ -390,6 +388,15 @@ Then, add those terms-of-use with the snf-manage command:
Your terms have been successfully added and you will see the corresponding link
appearing in the Astakos web pages' footer.
During the account registration, if there are approval terms, the user is
presented with an "I agree with the Terms" checkbox that needs to get checked
in order to proceed.
In case there are new approval terms that the user has not signed yet, the
``signed_terms_required`` view decorator redirects to the ``approval_terms``
view, so the user will be presented with the new terms the next time he/she
logins.
Enabling reCAPTCHA
~~~~~~~~~~~~~~~~~~
......@@ -417,6 +424,73 @@ Checkout your new Sign up page. If you see the reCAPTCHA box, you have setup
everything correctly.
Astakos internals
-----------------
X-Auth-Token
~~~~~~~~~~~~
Alice requests a specific resource from a cloud service e.g.: Pithos. In the
request she supplies the `X-Auth-Token` to identify whether she is eligible to
perform the specific task. The service contacts Astakos through its
``/account/v1.0/authenticate`` api call (see :ref:`authenticate-api-label`)
providing the specific ``X-Auth-Token``. Astakos checkes whether the token
belongs to an active user and it has not expired and returns a dictionary
containing user related information. Finally the service uses the ``uniq``
field included in the dictionary as the account string to identify the user
accessible resources.
.. _authentication-label:
Django Auth methods and Backends
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Astakos incorporates Django user authentication system and extends its User model.
Since username field of django User model has a limitation of 30 characters,
AstakosUser is **uniquely** identified by the ``email`` instead. Therefore,
``astakos.im.authentication_backends.EmailBackend`` is served to authenticate a
user using email if the first argument is actually an email, otherwise tries
the username.
A new AstakosUser instance is assigned with a uui as username and also with a
``auth_token`` used by the cloud services to authenticate the user.
``astakos.im.authentication_backends.TokenBackend`` is also specified in order
to authenticate the user using the email and the token fields.
Logged on users can perform a number of actions:
* access and edit their profile via: ``/im/profile``.
* change their password via: ``/im/password``
* send feedback for grnet services via: ``/im/send_feedback``
* logout (and delete cookie) via: ``/im/logout``
Internal Astakos requests are handled using cookie-based Django user sessions.
External systems should forward to the ``/login`` URI. The server,
depending on its configuration will redirect to the appropriate login page.
When done with logging in, the service's login URI should redirect to the URI
provided with next, adding user and token parameters, which contain the email
and token fields respectively.
The login URI accepts the following parameters:
====================== =========================
Request Parameter Name Value
====================== =========================
next The URI to redirect to when the process is finished
renew Force token renewal (no value parameter)
force Force logout current user (no value parameter)
====================== =========================
External systems inside the ``ASTAKOS_COOKIE_DOMAIN`` scope can acquire the
user information by the cookie identified by ``ASTAKOS_COOKIE_NAME`` setting
(set during the login procedure).
Finally, backend systems having acquired a token can use the
:ref:`authenticate-api-label` API call from a private network or through HTTPS.
File Storage Service (Pithos)
=============================
......
......@@ -3,194 +3,30 @@
Identity Management Service (Astakos)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Astakos is GRNET project that provides identity management, catalog and policy services.
It is designed to be used by the synnefo family software,
but is free and open to use by anybody, under a BSD-2 clause license.
Introduction
============
Astakos serves as a unique point of authentication for `GRNET <http://www.grnet.gr>`_
cloud services. It is a platform-wide service that allows users to manage their accounts.
Users in astakos can be authenticated via several identity providers:
* Local
* Shibboleth
It extends the ``snf-manage`` command line tool by introducing commands for managing the user accounts.
It is build over django and extends its authentication mechanism.
This document's goals are:
* present the overall architectural design.
* provide basic use cases.
The present document is meant to be read alongside the `Django documentation
<https://www.djangoproject.com/>`_. Thus, it is suggested that the reader is
familiar with associated technologies.
Astakos Architecture
====================
Overview
--------
Astakos service co-ordinates the access to resources (and the subsequent
permission model) and acts as the single point of registry and entry to the
GRNET cloud offering, comprising of Cyclades and Pithos subsystems.
It also propagates the user state to the Aquarium pricing subsystem.
.. image:: images/astakos-okeanos.jpg
Registration Use Cases
----------------------
The following subsections describe two basic registration use cases. All the
registration cases are illustrated in :ref:`registration-flow-label`
Invited user
~~~~~~~~~~~~
.. note::
Invitation feature is currently disabled.
A registered ~okeanos user, invites student Alice to subscribe to ~okeanos
services. Alice receives an email and through a link is navigated to Astakos's
signup page. The system prompts her to select one of the available
authentication mechanisms (Shibboleth, local authentication) in
order to register to the system. Alice already has a Shibboleth account so
chooses that and then she is redirected to her institution's login page. Upon
successful login, her account is created.
Since she is invited her account is automaticaly activated and she is
redirected to Astakos's login page. As this is the first time Alice has
accessed the system she is redirected to her profile page where she can edit or
provide more information.
Not invited user
~~~~~~~~~~~~~~~~
Tony while browsing in the internet finds out about ~okeanos services. He
visits the signup page and fills the signup form. Since his not an invited
user his account has to be activated from an administrator first,
in order to be able to login. Upon the account's activation he receives
an email and through a link he is redirected to the login page.
Authentication Use Cases
------------------------
Cloud service user
~~~~~~~~~~~~~~~~~~
Alice requests a specific resource from a cloud service ex. Pithos. In the
request supplies the `X-Auth-Token` to identify whether she is eligible to
perform the specific task. The service contacts Astakos through its
``/account/v1.0/authenticate`` api call (see :ref:`authenticate-api-label`)
providing the specific ``X-Auth-Token``. Astakos checkes whether the token
belongs to an active user and it has not expired and returns a dictionary
containing user related information. Finally the service uses the ``uniq``
field included in the dictionary as the account string to identify the user
accessible resources.
.. _registration-flow-label:
Registration Flow
-----------------
Responsible for handling the account registration and activation requests is the ``signup`` view. This view checks whether it is a request for a local account. If this is not the case, the user is navigated to the third-party provider to authenticate against it and upon success is redirected back in the ``signup`` view. If the supplied information is valid and an inactive account is created. Then the appropriate ``ActivationBackend`` handles the account activation: the ``InvitationsBackend`` if the invitation mechanism is enabled and the ``SimpleBackend`` otherwise.
In the first case, if the request is accompanied with a valid invitation code the user is automatically activated and since its email address (where received the invitation) is verified, acquires a valid token and is logged in the system. If there is no invitation associated with the request, the system check whether the email matches any of the ASTAKOS_RE_USER_EMAIL_PATTERNS and if it does it sends an email to the user to verify the email address, otherwise the system sends a notification email to the administrators and informs the user that the account activation will be moderated by them.
If the invitation mechanism is not enabled, the ``SimpleBackend`` checks if the email address matches any of the ASTAKOS_RE_USER_EMAIL_PATTERNS or the moderation is not enabled and it sends a verification email, otherwise informs the user that the account is pending approval and sends a notification email to the admins.
The verification email contains a link that navigates the user to ``activate`` view through a URI that contains also a temporary user token. If this token is valid the user account is activated and the user is logged in the system, after renewing the token and setting the cookie identified by ASTAKOS_COOKIE_NAME (used by the ~okeanos subcomponents).
If FORCE_PROFILE_UPDATE is set, after the first successful login the user is navigated first to the ``profile`` view, before been redirected to the ``next`` parameter value.
.. image:: images/astakos-signup.jpg
:scale: 80%
Login Flow
----------
During loging procedure the user is authenticated by the respective identity provider.
If ASTAKOS_RECAPTCHA_ENABLED is set and the user fails several times (ASTAKOS_RATELIMIT_RETRIES_ALLOWED setting) to provide the correct credentials for a local account, is prompted to solve a captcha challenge.
Upon success, the system renews the token (if it has been expired), logins the user and sets the cookie, before redirecting the user to the ``next`` parameter value.
.. image:: images/astakos-login.jpg
:scale: 80%
Approval Terms
--------------
The ``snf-manage addterms`` command serves to add new approval terms.
During the account registration, if there are approval terms, the user has to agree with them in order to proceed.
In case there are later approval terms that the user has not signed, the ``signed_terms_required`` view decorator redirects to the ``approval_terms`` view.
Service Registration
--------------------
Services (ex. Cyclades, Pithos) are registered in astakos via ``snf-manage registerservice``. This command generates and prints a service token useful for accessing the service API.
Registered services can be viewed by ``snf-manage showservices`` command and ``snf-manage unregisterservice`` can be used to unregister a service.
.. _authentication-label:
Astakos Users and Authentication
--------------------------------
Astakos incorporates django user authentication system and extends its User model.
Since username field of django User model has a limitation of 30 characters,
AstakosUser is **uniquely** identified by the ``email`` instead. Therefore,
``astakos.im.authentication_backends.EmailBackend`` is served to authenticate a
user using email if the first argument is actually an email, otherwise tries
the username.
A new AstakosUser instance is assigned with a uui as username and also with a
``auth_token`` used by the cloud services to authenticate the user.
``astakos.im.authentication_backends.TokenBackend`` is also specified in order
to authenticate the user using the email and the token fields.
Logged on users can perform a number of actions:
* access and edit their profile via: ``/im/profile``.
* change their password via: ``/im/password``
* invite somebody else via: ``/im/invite``
* send feedback for grnet services via: ``/im/send_feedback``
* logout (and delete cookie) via: ``/im/logout``
User entries can also be modified/added via the ``snf-manage`` commands.
Internal Astakos requests are handled using cookie-based django user sessions.
External systems should forward to the ``/login`` URI. The server,
depending on its configuration will redirect to the appropriate login page.
When done with logging in, the service's login URI should redirect to the URI
provided with next, adding user and token parameters, which contain the email
and token fields respectively.
The login URI accepts the following parameters:
====================== =========================
Request Parameter Name Value
====================== =========================
next The URI to redirect to when the process is finished
renew Force token renewal (no value parameter)
force Force logout current user (no value parameter)
====================== =========================
External systems inside the ASTAKOS_COOKIE_DOMAIN scope can acquire the user information by the
cookie identified by ASTAKOS_COOKIE_NAME setting (set during the login procedure).
Finally, backend systems having acquired a token can use the
:ref:`authenticate-api-label` api call from a private network or through HTTPS.
Astakos is the Identity management component which provides a common user base
to the rest of Synnefo. Astakos handles user creation, user groups, resource
accounting, quotas, projects, and issues authentication tokens used across the
infrastructure. It supports multiple authentication methods:
* local username/password
* LDAP / Active Directory
* SAML 2.0 (Shibboleth) federated logins
* Google
* Twitter
* LinkedIn
Users can add multiple login methods to a single account, according to
configured policy.
Astakos keeps track of resource usage across Synnefo, enforces quotas, and
implements a common user dashboard. Quota handling is resource type agnostic:
Resources (e.g., VMs, public IPs, GBs of storage, or disk space) are defined by
each Synnefo component independently, then imported into Astakos for accounting
and presentation.
Astakos runs at the cloud layer and exposes the OpenStack Keystone API for
authentication, along with the Synnefo Account API for quota, user group and
project management.
Please also see the :ref:`Admin Guide <admin-guide>` for more information and the
:ref:`Installation Guide <quick-install-admin-guide>` for installation instructions.
......@@ -3,28 +3,24 @@ Welcome to Synnefo's documentation
.. image:: /images/synnefo-logo.png
| Synnefo is open source cloud software, used to create massively scalable IaaS
clouds.
| Synnefo uses `Google Ganeti <http://code.google.com/p/ganeti/>`_ for the low
level VM management part.
Synnefo is a complete open source cloud stack written in Python that provides
Compute, Network, Image, Volume and Storage services, similar to the ones
offered by AWS. Synnefo manages multiple `Ganeti
<http://code.google.com/p/ganeti>`_ clusters at the backend for handling of
low-level VM operations. To boost 3rd-party compatibility, Synnefo exposes the
OpenStack APIs to users.
| You can see Synnefo in action, powering GRNET's
`~okeanos public cloud service <http://okeanos.io>`_.
| It is a collection of components (``snf-*``), most of them written in python, that
are used as the building bricks to provide the following services:
You can see Synnefo in action, powering GRNET's
`~okeanos public cloud service <http://okeanos.grnet.gr>`_.
Synnefo has three main components providing the corresponding services:
.. toctree::
:maxdepth: 1
Identity Management (codename: astakos) <astakos>
Object Storage Service (codename: pithos) <pithos>
Compute Service (codename: cyclades) <cyclades>
Network Service (part of Cyclades) <networks>
Image Service (part of Cyclades) <plankton>
Volume Storage Service (codename: archipelago) <archipelago>
.. image:: images/synnefo-overview.png
:target: _images/synnefo-overview.png
Astakos: Identity/Account services <astakos>
Pithos: File/Object Storage service <pithos>
Cyclades: Compute/Network/Image/Volume services <cyclades>
There are also the following tools:
......@@ -37,6 +33,10 @@ There are also the following tools:
snf-image: Secure image deployment tool <snf-image>
snf-burnin: Integration testing tool for a running Synnefo deployment <snf-burnin>
This is an overview of the Synnefo services:
.. image:: images/synnefo-overview.png
:target: _images/synnefo-overview.png
Synnefo is designed to be as simple, scalable and production ready as possible.
Furthermore, although it can be deployed in small configurations, its prime
......@@ -46,7 +46,6 @@ All Synnefo components use an intuitive settings mechanism, that adds and remove
settings dynamically as components are getting added or removed from a physical
node. All settings are stored in a single location.
.. _general-arch:
Synnefo General Architecture
......@@ -63,7 +62,6 @@ Synnefo also supports RADOS as an alternative storage backend for
Files/Images/VM disks. :ref:`Here <syn+archip+rados>` is a graph that shows
Synnefo running with two different storage backends.
Synnefo Guides
==============
......@@ -159,7 +157,6 @@ The official site is:
`http://www.synnefo.org <http://www.synnefo.org>`_
Indices and tables
==================
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment