Revision 8f9976c6 docs/astakos.rst
b/docs/astakos.rst | ||
---|---|---|
5 | 5 |
|
6 | 6 |
Astakos is the synnefo Identity Management Service. |
7 | 7 |
|
8 |
Introduction |
|
9 |
============ |
|
10 |
|
|
11 |
Astakos serves as the point of authentication for GRNET (http://www.grnet.gr) |
|
12 |
services. It is a platform-wide service, allowing users to register, login, and |
|
13 |
keep track of permissions. |
|
14 |
|
|
15 |
Users in astakos can be authenticated via several identity providers: |
|
16 |
|
|
17 |
* Local |
|
18 |
|
|
19 |
* Shibboleth |
|
20 |
|
|
21 |
It provides also a command line tool for managing 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 |
|
|
8 | 35 |
Astakos Architecture |
9 | 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/~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 covered in :ref:`registration-flow-label` |
|
54 |
|
|
55 |
Invited user |
|
56 |
~~~~~~~~~~~~ |
|
57 |
|
|
58 |
A registered ~okeanos user, invites student Alice to subscribe to ~okeanos |
|
59 |
services. Alice receives an email and through a link is navigated to Astakos's |
|
60 |
signup page. The system prompts her to select one of the available |
|
61 |
authentication mechanisms (Shibboleth, Twitter or local authentication) in |
|
62 |
order to register to the system. Alice already has a Shibboleth account so |
|
63 |
chooses that and then she is redirected to her institution's login page. Upon |
|
64 |
successful login, her account is created. |
|
65 |
|
|
66 |
Since she is invited his account is automaticaly activated and she is |
|
67 |
redirected to Astakos's login page. As this is the first time Alice has |
|
68 |
accessed the system she is redirected to her profile page where she can edit or |
|
69 |
provide more information. |
|
70 |
|
|
71 |
Not invited user |
|
72 |
~~~~~~~~~~~~~~~~ |
|
73 |
|
|
74 |
Tony while browsing in the internet finds out about ~okeanos services. He |
|
75 |
visits the signup page and since his has already a twitter account selects the |
|
76 |
twitter authentication mechanism and he is redirected to twitter login page |
|
77 |
where he is promted to provide his credentials. Upon successful login, twitter |
|
78 |
redirects him back to the Astakos and the account is created. |
|
79 |
|
|
80 |
Since his not an invited user his account has to be activated from an |
|
81 |
administrator first, in order to be able to login. Upon the account's |
|
82 |
activation he receives an email and through a link he is redirected to the |
|
83 |
login page. |
|
84 |
|
|
85 |
Authentication Use Cases |
|
86 |
------------------------ |
|
87 |
|
|
88 |
Cloud service user |
|
89 |
~~~~~~~~~~~~~~~~~~ |
|
90 |
|
|
91 |
Alice requests a specific resource from a cloud service ex. Pithos. In the |
|
92 |
request supplies the `X-Auth-Token`` to identify whether she is eligible to |
|
93 |
perform the specific task. The service contacts Astakos through its |
|
94 |
``/im/authenticate`` api call (see :ref:`authenticate-api-label`) providing the |
|
95 |
specific ``X-Auth-Token``. Astakos checkes whether the token belongs to an |
|
96 |
active user and it has not expired and returns a dictionary containing user |
|
97 |
related information. Finally the service uses the ``uniq`` field included in |
|
98 |
the dictionary as the account string to identify the user accessible resources. |
|
99 |
|
|
100 |
.. _registration-flow-label: |
|
101 |
|
|
102 |
Registration Flow |
|
103 |
----------------- |
|
104 |
|
|
105 |
.. image:: images/signup.jpg |
|
106 |
:scale: 100% |
|
107 |
|
|
108 |
Login Flow |
|
109 |
---------- |
|
110 |
.. image:: images/login.jpg |
|
111 |
:scale: 100% |
|
112 |
|
|
113 |
.. _authentication-label: |
|
114 |
|
|
115 |
Astakos Users and Authentication |
|
116 |
-------------------------------- |
|
117 |
|
|
118 |
Astakos incorporates django user authentication system and extends its User model. |
|
119 |
|
|
120 |
Since username field of django User model has a limitation of 30 characters, |
|
121 |
AstakosUser is **uniquely** identified by the ``email`` instead. Therefore, |
|
122 |
``astakos.im.authentication_backends.EmailBackend`` is served to authenticate a |
|
123 |
user using email if the first argument is actually an email, otherwise tries |
|
124 |
the username. |
|
125 |
|
|
126 |
A new AstakosUser instance is assigned with a uui as username and also with a |
|
127 |
``auth_token`` used by the cloud services to authenticate the user. |
|
128 |
``astakos.im.authentication_backends.TokenBackend`` is also specified in order |
|
129 |
to authenticate the user using the email and the token fields. |
|
130 |
|
|
131 |
Logged on users can perform a number of actions: |
|
132 |
|
|
133 |
* access and edit their profile via: ``/im/profile``. |
|
134 |
* change their password via: ``/im/password`` |
|
135 |
* invite somebody else via: ``/im/invite`` |
|
136 |
* send feedback for grnet services via: ``/im/send_feedback`` |
|
137 |
* logout (and delete cookie) via: ``/im/logout`` |
|
138 |
|
|
139 |
User entries can also be modified/added via the ``snf-manage activateuser`` command. |
|
140 |
|
|
141 |
A superuser account can be created the first time you run the ``manage.py |
|
142 |
syncdb`` django command and then loading the extra user data from the |
|
143 |
``admin_user`` fixture. At a later date, the ``manage.py createsuperuser`` |
|
144 |
command line utility can be used (as long as the extra user data for Astakos is |
|
145 |
added with a fixture or by hand). |
|
146 |
|
|
147 |
Internal Astakos requests are handled using cookie-based django user sessions. |
|
148 |
|
|
149 |
External systems in the same domain can delgate ``/login`` URI. The server, |
|
150 |
depending on its configuration will redirect to the appropriate login page. |
|
151 |
When done with logging in, the service's login URI should redirect to the URI |
|
152 |
provided with next, adding user and token parameters, which contain the email |
|
153 |
and token fields respectively. |
|
154 |
|
|
155 |
The login URI accepts the following parameters: |
|
156 |
|
|
157 |
====================== ========================= |
|
158 |
Request Parameter Name Value |
|
159 |
====================== ========================= |
|
160 |
next The URI to redirect to when the process is finished |
|
161 |
renew Force token renewal (no value parameter) |
|
162 |
force Force logout current user (no value parameter) |
|
163 |
====================== ========================= |
|
164 |
|
|
165 |
External systems outside the domain scope can acquire the user information by a |
|
166 |
cookie set identified by ASTAKOS_COOKIE_NAME setting. |
|
167 |
|
|
168 |
Finally, backend systems having acquired a token can use the |
|
169 |
:ref:`authenticate-api-label` api call from a private network or through HTTPS. |
|
170 |
|
Also available in: Unified diff