Revision 949f8393 docs/astakos.rst
b/docs/astakos.rst | ||
---|---|---|
84 | 84 |
~~~~~~~~~~~~~~~~~~ |
85 | 85 |
|
86 | 86 |
Alice requests a specific resource from a cloud service ex. Pithos+. In the |
87 |
request supplies the `X-Auth-Token`` to identify whether she is eligible to
|
|
87 |
request supplies the `X-Auth-Token` to identify whether she is eligible to |
|
88 | 88 |
perform the specific task. The service contacts Astakos through its |
89 | 89 |
``/im/authenticate`` api call (see :ref:`authenticate-api-label`) providing the |
90 | 90 |
specific ``X-Auth-Token``. Astakos checkes whether the token belongs to an |
... | ... | |
97 | 97 |
Registration Flow |
98 | 98 |
----------------- |
99 | 99 |
|
100 |
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 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. |
|
100 |
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.
|
|
101 | 101 |
|
102 | 102 |
In the first case, if the request is accompanied with a valid invitation code the user is automatically activated and since it's 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. |
103 | 103 |
|
... | ... | |
131 | 131 |
|
132 | 132 |
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. |
133 | 133 |
|
134 |
Service Registration |
|
135 |
-------------------- |
|
136 |
|
|
137 |
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. |
|
138 |
Registered services can be viewed by ``snf-manage showservices`` command and ``snf-manage unregisterservice`` can be used to unregister a service. |
|
139 |
|
|
134 | 140 |
.. _authentication-label: |
135 | 141 |
|
136 | 142 |
Astakos Users and Authentication |
... | ... | |
161 | 167 |
|
162 | 168 |
Internal Astakos requests are handled using cookie-based django user sessions. |
163 | 169 |
|
164 |
External systems can delgate ``/login`` URI. The server,
|
|
170 |
External systems should forward to the ``/login`` URI. The server,
|
|
165 | 171 |
depending on its configuration will redirect to the appropriate login page. |
166 | 172 |
When done with logging in, the service's login URI should redirect to the URI |
167 | 173 |
provided with next, adding user and token parameters, which contain the email |
Also available in: Unified diff