Revision 71053581 docs/upgrade/upgrade-0.15.rst
b/docs/upgrade/upgrade-0.15.rst | ||
---|---|---|
176 | 176 |
'https://accounts.example.synnefo.org/identity/v2.0'. |
177 | 177 |
|
178 | 178 |
For Pithos service we have to change the ``20-snf-pithos-app-settings.conf`` |
179 |
file in the same way as above. |
|
179 |
file in the same way as above. In addition to this, we have to change the |
|
180 |
``PITHOS_OAUTH2_CLIENT_CREDENTIALS`` setting in the same configuration file |
|
181 |
to set the credentials issued for the pithos view in `the previous step`__. |
|
180 | 182 |
|
181 |
2.4 Upgrade vncauthproxy and configure snf-cyclades-app |
|
183 |
__ pithos_view_registration_ |
|
184 |
|
|
185 |
|
|
186 |
2.5 Upgrade vncauthproxy and configure snf-cyclades-app |
|
182 | 187 |
------------------------------------------------------- |
183 | 188 |
|
184 | 189 |
Synnefo v0.15 adds support for snf-vncauthproxy >= 1.5 and drops support for |
... | ... | |
226 | 231 |
<http://www.synnefo.org/docs/snf-vncauthproxy/latest/index.html>`_ of |
227 | 232 |
snf-vncauthproxy for more information on upgrading to version 1.5. |
228 | 233 |
|
229 |
2.5 Stats configuration
|
|
234 |
2.6 Stats configuration
|
|
230 | 235 |
----------------------- |
231 | 236 |
|
232 | 237 |
snf-cyclades-gtools comes with a collectd plugin to collect CPU and network |
... | ... | |
258 | 263 |
setting (used to decrypt the instance hostname) in |
259 | 264 |
``20-snf-stats-settings.conf`` on your Stats host. |
260 | 265 |
|
261 |
In addition to this, we have to change the ``PITHOS_OAUTH2_CLIENT_CREDENTIALS`` |
|
262 |
setting in the ``20-snf-pithos-app-settings.conf`` file to set the credentials |
|
263 |
issued for the pithos view in `the previous step`__. |
|
266 |
2.7 Shibboleth configuration updates |
|
267 |
------------------------------------ |
|
264 | 268 |
|
265 |
__ pithos_view_registration_ |
|
269 |
.. note:: |
|
270 |
|
|
271 |
Skip this step unless you have ``shibboleth`` enabled in astakos |
|
272 |
``IM_MODULES`` setting. |
|
273 |
|
|
274 |
As of v0.15 astakos uses the ``REMOTE_USER`` header provided by apache's |
|
275 |
``mod_shib2`` service in order to resolve the unique identifier which is used to |
|
276 |
associate a shibboleth account to a local astakos user. Prior to this version |
|
277 |
astakos adhered to the presence of the ``MOD_SHIB_EPPN`` header which although |
|
278 |
safe enough on most of the ``SP`` deployment scenarios, it may cause issues in |
|
279 |
certain cases, such as global wide IdP support or inability of supported IdPs |
|
280 |
to release the ``eduPersonPrincipalName`` attribute. The ``REMOTE_USER`` header |
|
281 |
can be set by administrators to match any of the available shibboleth |
|
282 |
attributes. |
|
283 |
|
|
284 |
If ``EPPN`` matches the service provider needs and you want to continue using |
|
285 |
it as the unique identifier, you need to ensure that the ``REMOTE_USER`` |
|
286 |
attribute is set to ``eppn`` in the ``mod_shib2`` config file located at |
|
287 |
``/etc/shibboleth/shibboleth2.xml`` |
|
288 |
|
|
289 |
.. code-block:: xml |
|
290 |
|
|
291 |
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. --> |
|
292 |
<ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="eppn"> |
|
293 |
|
|
294 |
Otherwise, if ``EPPN`` doesn't suit the requirements for your ``SP`` |
|
295 |
deployment, change the ``REMOTE_USER`` attribute as required e.g.: |
|
296 |
|
|
297 |
.. code-block:: xml |
|
298 |
|
|
299 |
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. --> |
|
300 |
<ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="persistent-nameid persistent-id targeted-id"> |
|
301 |
|
|
302 |
and restart the ``shibd`` service: |
|
303 |
|
|
304 |
.. code-block:: console |
|
305 |
|
|
306 |
$ service shibd restart |
|
307 |
|
|
308 |
**notice** that every time you alter the ``REMOTE_USER`` attribute, all |
|
309 |
existing shibboleth enabled astakos users will be invalidated and no longer be |
|
310 |
able to login to their existing account using shibboleth. Specifically for the |
|
311 |
case of switching from *eppn* to another attribute, astakos is able to prevent |
|
312 |
invalidation and automatically migrate existing *eppn* accounts. In order to do |
|
313 |
that, set the ``ASTAKOS_SHIBBOLETH_MIGRATE_EPPN`` setting to ``True`` in |
|
314 |
``20-snf-astakos-app-settings.conf`` configuration file. Now every time an |
|
315 |
existing *eppn* user logs in using shibboleth, astakos will update the associated |
|
316 |
*eppn* identifier to the contents of the ``REMOTE_USER`` header. |
|
317 |
|
|
318 |
.. warning:: |
|
319 |
|
|
320 |
IdPs should keep releasing the ``EPPN`` attribute in order for the migration |
|
321 |
to work. |
|
266 | 322 |
|
267 | 323 |
3. Create floating IP pools |
268 | 324 |
=========================== |
Also available in: Unified diff