Statistics
| Branch: | Tag: | Revision:

root / docs / astakos.rst @ d29f0371

History | View | Annotate | Download (9.1 kB)

1
.. _astakos:
2

    
3
Identity Management Service (Astakos)
4
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5

    
6
Astakos is GRNET project that provides identity management, catalog and policy services.
7
It is designed to be used by the synnefo family software,
8
but is free and open to use by anybody, under a BSD-2 clause license.
9

    
10
Introduction
11
============
12

    
13
Astakos serves as a unique point of authentication for `GRNET <http://www.grnet.gr>`_
14
cloud services. It is a platform-wide service that allows users to manage their accounts.
15

    
16
Users in astakos can be authenticated via several identity providers:
17

    
18
 * Local
19
 * Shibboleth
20

    
21
It extends the ``snf-manage`` command line tool by introducing commands for managing the user accounts.
22

    
23
It is build over django and extends its authentication mechanism.
24

    
25
This document's goals are:
26

    
27
 * present the overall architectural design.
28
 * provide basic use cases.
29

    
30
The present document is meant to be read alongside the `Django documentation
31
<https://www.djangoproject.com/>`_. Thus, it is suggested that the reader is
32
familiar with associated technologies.
33

    
34

    
35
Astakos Architecture
36
====================
37

    
38
Overview
39
--------
40

    
41
Astakos service co-ordinates the access to resources (and the subsequent
42
permission model) and acts as the single point of registry and entry to the
43
GRNET cloud offering, comprising of Cyclades and Pithos subsystems.
44

    
45
It also propagates the user state to the Aquarium pricing subsystem.
46

    
47
.. image:: images/astakos-okeanos.jpg
48

    
49
Registration Use Cases
50
----------------------
51

    
52
The following subsections describe two basic registration use cases. All the
53
registration cases are illustrated in :ref:`registration-flow-label`
54

    
55
Invited user
56
~~~~~~~~~~~~
57

    
58
.. note::
59

    
60
   Invitation feature is currently disabled.
61

    
62
A registered ~okeanos user, invites student Alice to subscribe to ~okeanos
63
services. Alice receives an email and through a link is navigated to Astakos's
64
signup page. The system prompts her to select one of the available
65
authentication mechanisms (Shibboleth, local authentication) in
66
order to register to the system. Alice already has a Shibboleth account so
67
chooses that and then she is redirected to her institution's login page. Upon
68
successful login, her account is created.
69

    
70
Since she is invited her account is automaticaly activated and she is
71
redirected to Astakos's login page. As this is the first time Alice has
72
accessed the system she is redirected to her profile page where she can edit or
73
provide more information.
74

    
75
Not invited user
76
~~~~~~~~~~~~~~~~
77

    
78
Tony while browsing in the internet finds out about ~okeanos services. He
79
visits the signup page and fills the signup form. Since his not an invited
80
user his account has to be activated from an administrator first,
81
in order to be able to login. Upon the account's activation he receives
82
an email and through a link he is redirected to the login page.
83

    
84
Authentication Use Cases
85
------------------------
86

    
87
Cloud service user
88
~~~~~~~~~~~~~~~~~~
89

    
90
Alice requests a specific resource from a cloud service ex. Pithos. In the
91
request supplies the `X-Auth-Token` to identify whether she is eligible to
92
perform the specific task. The service contacts Astakos through its
93
``/account/v1.0/authenticate`` api call (see :ref:`authenticate-api-label`)
94
providing the specific ``X-Auth-Token``. Astakos checkes whether the token
95
belongs to an active user and it has not expired and returns a dictionary
96
containing user related information. Finally the service uses the ``uniq``
97
field included in the dictionary as the account string to identify the user
98
accessible resources.
99

    
100
.. _registration-flow-label:
101

    
102
Registration Flow
103
-----------------
104

    
105
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.
106

    
107
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.
108

    
109
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.
110

    
111
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).
112

    
113
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.
114

    
115
.. image:: images/astakos-signup.jpg
116
    :scale: 80%
117

    
118
Login Flow
119
----------
120

    
121
During loging procedure the user is authenticated by the respective identity provider.
122

    
123
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.
124

    
125
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.
126

    
127
.. image:: images/astakos-login.jpg
128
    :scale: 80%
129

    
130
Approval Terms
131
--------------
132

    
133
The ``snf-manage addterms`` command serves to add new approval terms.
134

    
135
During the account registration, if there are approval terms, the user has to agree with them in order to proceed.
136

    
137
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.
138

    
139
Service Registration
140
--------------------
141

    
142
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.
143
Registered services can be viewed by ``snf-manage showservices`` command and ``snf-manage unregisterservice`` can be used to unregister a service.
144

    
145
.. _authentication-label:
146

    
147
Astakos Users and Authentication
148
--------------------------------
149

    
150
Astakos incorporates django user authentication system and extends its User model.
151

    
152
Since username field of django User model has a limitation of 30 characters,
153
AstakosUser is **uniquely** identified by the ``email`` instead. Therefore,
154
``astakos.im.authentication_backends.EmailBackend`` is served to authenticate a
155
user using email if the first argument is actually an email, otherwise tries
156
the username.
157

    
158
A new AstakosUser instance is assigned with a uui as username and also with a
159
``auth_token`` used by the cloud services to authenticate the user.
160
``astakos.im.authentication_backends.TokenBackend`` is also specified in order
161
to authenticate the user using the email and the token fields.
162

    
163
Logged on users can perform a number of actions:
164

    
165
 * access and edit their profile via: ``/im/profile``.
166
 * change their password via: ``/im/password``
167
 * invite somebody else via: ``/im/invite``
168
 * send feedback for grnet services via: ``/im/send_feedback``
169
 * logout (and delete cookie) via: ``/im/logout``
170

    
171
User entries can also be modified/added via the ``snf-manage`` commands.
172

    
173
Internal Astakos requests are handled using cookie-based django user sessions.
174

    
175
External systems should forward to the ``/login`` URI. The server,
176
depending on its configuration will redirect to the appropriate login page.
177
When done with logging in, the service's login URI should redirect to the URI
178
provided with next, adding user and token parameters, which contain the email
179
and token fields respectively.
180

    
181
The login URI accepts the following parameters:
182

    
183
======================  =========================
184
Request Parameter Name  Value
185
======================  =========================
186
next                    The URI to redirect to when the process is finished
187
renew                   Force token renewal (no value parameter)
188
force                   Force logout current user (no value parameter)
189
======================  =========================
190

    
191
External systems inside the ASTAKOS_COOKIE_DOMAIN scope can acquire the user information by the
192
cookie identified by ASTAKOS_COOKIE_NAME setting (set during the login procedure).
193

    
194
Finally, backend systems having acquired a token can use the
195
:ref:`authenticate-api-label` api call from a private network or through HTTPS.
196