minor updates to op guide

documentation/operator-guide/access.rst

@@ -68,7 +68,7 @@ Currently setting individual authorization rules on a ``Collection`` and ``Servi
 
 Configuration
 ~~~~~~~~~~~~~
-For correct configuration of Shibboleth SP3 on a new stack, several steps need to be done. Most of these configurations are usually done in the :ref:`_initialization` step using ``pvs_starter`` tool. Still, it is advised to check following steps, understand them and change if necessary.
+For correct configuration of Shibboleth SP3 on a new stack, several steps need to be done. Most of these configurations are usually done in the :ref:`initialization` step using ``pvs_starter`` tool. Still, it is advised to check following steps, understand them and change if necessary.
 Briefly summarized, SP and IdP need to exchange metadata and certificates to trust each other, SP needs to know which attributes the IdP will be sending about the logged-in user and respective access-control rules are configured based on those attributes. Most of the configurations are done via docker configs defined in the docker compose 
 
 - Create a pair of key, certificate using attached Shibboleth ``config/shibboleth/keygen.sh`` in the cloned vs repository and save them as respective docker secrets.
@@ -81,6 +81,7 @@ Briefly summarized, SP and IdP need to exchange metadata and certificates to tru
  docker secret create <stack-name>_SHIB_KEY sp-signing-key.pem 
 
 - Get IDP metadata and save it as a docker config. Also read the entityID of the IdP for further use in referencing it in your ``shibboleth2.xml`` configuration.
+
 .. code-block:: bash
 
  docker config create idp-metadata idp-metadata-received.xml 
@@ -88,13 +89,14 @@ Briefly summarized, SP and IdP need to exchange metadata and certificates to tru
 - Configure Apache ServerName used inside the ``shibauth`` service by modifying ``APACHE_SERVERNAME`` environment variable of corresponding ``shibauth`` service in ``docker-compose.<stack>.ops.yml``. This URL should resolve to the actual service URL.
 
 - Modify shibboleth2.xml content by setting your "entityID" in <ApplicationDefaults> Additionally edit the "entityID" value inside ``SSO`` element to match the IdP "entityID". Note that "entityID" does not need to resolve to an actual service URL.
+
 .. code-block:: xml
- 
- <ApplicationDefaults entityID="https://testing-sp/shibboleth"
- ...
- <SSO entityID="https://testing-idp:443/shibboleth">
-   SAML2 
- </SSO>
+
+ <ApplicationDefaults entityID="https://testing-sp/shibboleth">
+   <SSO entityID="https://testing-idp:443/shibboleth">
+     SAML2 
+   </SSO>
+ </ApplicationDefaults>
 
 - Deploy your shibauth service and exchange your SP metadata with the IdP provider and have them recognize your SP. Necessary metadata needs to be downloaded from url ``<service-url>/Shibboleth.sso/Metadata``.
 
@@ -108,6 +110,7 @@ Briefly summarized, SP and IdP need to exchange metadata and certificates to tru
  </Attributes>
 
 - Create custom access rules based on these attributes and map these access controls to different internal apache routes to which Traefik ForwardAuth middleware will point. Access rules are created in ``config/shibboleth/<stack-name>-ac.xml``.
+
 Example of external Access control rules configuration:
 
 .. code-block:: xml

documentation/operator-guide/management.rst

@@ -116,6 +116,7 @@ In order to select any other option from the Kibana toolkit, click the horizonta
 
 .. _fig_kibana_menu:
 .. figure:: images/kibana_1.*
+   :width: 250
    :alt: Kibana menu
 
    *Kibana menu*