diff --git a/doc/source/cli_examples.rst b/doc/source/cli_examples.rst index b76f575c85..25c5c1566f 100644 --- a/doc/source/cli_examples.rst +++ b/doc/source/cli_examples.rst @@ -18,16 +18,496 @@ Command Line Interface Examples =============================== +The Keystone command line interface packaged in `python-keystoneclient`_ only +supports the Identity v2.0 API. The OpenStack common command line interface +packaged in `python-openstackclient`_ supports both v2.0 and v3 APIs. + +.. NOTE:: + + As of the Juno release, it is recommended to use ``python-openstackclient``, + as it suports both v2.0 and v3 APIs. For the purpose of backwards compatibility, + the CLI packaged in ``python-keystoneclient`` is not being removed. + +.. _`python-openstackclient`: http://docs.openstack.org/developer/python-openstackclient/ +.. _`python-keystoneclient`: http://docs.openstack.org/developer/python-keystoneclient/ + +Using python-openstackclient (v3) +================================= + +Note that if using ``python-openstackclient`` for v3 commands, the following +environment variables must be updated: + +.. code-block:: bash + + $ export OS_IDENTITY_API_VERSION=3 (Defaults to 2.0) + $ export OS_AUTH_URL=http://localhost:5000/v3 + +Since Identity API v3 authentication is a bit more complex, there are additional +options that may be set, either as command options or environment variables. +The most common case will be a user supplying both user name and password, along +with the project name; previously in v2.0 this would be sufficient, but since +Identity API v3 has a ``Domain`` component, we need to tell the client in which +domain the user and project exists. + +If using a project name as authorization scope, set either of these: + + * ``--os-project-domain-name OS_PROJECT_DOMAIN_NAME`` Domain name of the project + which is the requested project-level authorization scope + * ``--os-project-domain-id OS_PROJECT_DOMAIN_ID`` Domain ID of the project which + is the requested project-level authorization scope + +Note, if using a project ID as authorization scope, then it is not required to +set ``OS_PROJECT_DOMAIN_NAME`` or ``OS_PROJECT_DOMAIN_ID``, the project ID is +sufficient. + +If using user name and password, set either of these: + + * ``--os-user-domain-name OS_USER_DOMAIN_NAME`` Domain name of the user + * ``--os-user-domain-id OS_USER_DOMAIN_ID`` Domain ID of the user + +If using a domain as authorization scope, set either of these: + + * ``--os-domain-name OS_DOMAIN_NAME``: Domain name of the requested domain-level + authorization scope + * ``--os-domain-id OS_DOMAIN_ID``: Domain ID of the requested domain-level + authorization scope + +In the examples below, the following are set: + +.. code-block:: bash + + $ export OS_IDENTITY_API_VERSION=3 + $ export OS_AUTH_URL=http://localhost:5000/v3 + $ export OS_PROJECT_DOMAIN_ID=default + $ export OS_USER_DOMAIN_ID=default + $ export OS_USERNAME=admin + $ export OS_PASSWORD=openstack + $ export OS_PROJECT_NAME=admin + +-------- +Projects +-------- + +``project create`` +------------------ + +positional arguments:: + + New project name + +optional arguments:: + + --description New project description + --domain Domain owning the project (name or ID) + + --enable Enable project (default) + --disable Disable project + +example: + +.. code-block:: bash + + $ openstack project create heat-project --domain heat + +Other commands +-------------- + +.. code-block:: bash + + $ openstack project delete + $ openstack project list + $ openstack project set + $ openstack project show + +----- +Users +----- + +``user create`` +--------------- + +positional arguments:: + + New user name + +optional arguments:: + + --password New user password + --password-prompt Prompt interactively for password + --email New user email address + --project Set default project (name or ID) + --domain New default domain name or ID + --enable Enable user (default) + --disable Disable user + + +example: + +.. code-block:: bash + + $ openstack user create heat-user \ + --password secrete \ + --domain heat \ + --project demo \ + --email admin@example.com + +Other commands +-------------- + +.. code-block:: bash + + $ openstack user delete + $ openstack user list + $ openstack user set + $ openstack user show + +------ +Groups +------ + +``group create`` +---------------- + +positional arguments:: + + New group name + +optional arguments:: + + --description New group description + --domain References the domain ID or name which owns the group + +example: + +.. code-block:: bash + + $ openstack group create heat-group --domain heat + +Other commands +-------------- + +.. code-block:: bash + + $ openstack group delete + $ openstack group list + $ openstack group set + $ openstack group show + +------- +Domains +------- + +``domain create`` +----------------- + +positional arguments:: + + New domain name + +optional arguments:: + + --description New domain description + --enable Enable domain + --disable Disable domain + + +example: + +.. code-block:: bash + + $ openstack domain create heat --description "Heat domain for heat users" + +Other commands +-------------- + +.. code-block:: bash + + $ openstack domain delete + $ openstack domain list + $ openstack domain set + $ openstack domain show + +Using python-openstackclient (v2.0) +=================================== + +-------- +Projects +-------- + +``project create`` +------------------ + +positional arguments:: + + New project name + +optional arguments:: + + --description New project description + --enable Enable project (default) + --disable Disable project + +example: + +.. code-block:: bash + + $ openstack project create demo + + +``project delete`` +------------------ + +positional arguments:: + + Project to delete (name or ID) + +example: + +.. code-block:: bash + + $ openstack project delete demo + +----- +Users +----- + +``user create`` +--------------- + +positional arguments:: + + New user name + +optional arguments:: + + --password New user password + --password-prompt Prompt interactively for password + --email New user email address + --project Set default project (name or ID) + --enable Enable user (default) + --disable Disable user + + +example: + +.. code-block:: bash + + $ openstack user create heat-user \ + --password secrete \ + --project demo \ + --email admin@example.com + +``user delete`` +--------------- + +positional arguments:: + + User to delete (name or ID) + +example: + +.. code-block:: bash + + $ openstack user delete heat-user + +``user list`` +------------- + +optional arguments:: + + --project Filter users by project (name or ID) + --long List additional fields in output + +example: + +.. code-block:: bash + + $ openstack user list + +``user set`` +------------ + +positional arguments:: + + User to change (name or ID) + +optional arguments:: + + --name New user name + --password New user password + --password-prompt Prompt interactively for password + --email New user email address + --project New default project (name or ID) + --enable Enable user (default) + --disable Disable user + + +example: + +.. code-block:: bash + + $ openstack user set heat-user --email newemail@example.com + +----- +Roles +----- + +``role create`` +--------------- + +positional arguments:: + + New role name + +example: + +.. code-block:: bash + + $ openstack role create demo + +``role delete`` +--------------- + +positional arguments:: + + Name or ID of role to delete + +example: + +.. code-block:: bash + + $ openstack role delete demo + +``role list`` +------------- + +example: + +.. code-block:: bash + + $ openstack role list + +``role show`` +------------- + +positional arguments:: + + Name or ID of role to display + +example: + +.. code-block:: bash + + $ openstack role show demo + + +``role add`` +------------ + +positional arguments:: + + Role name or ID to add to user + +optional arguments:: + + --project Include project (name or ID) + --user Name or ID of user to include + + +example: + +.. code-block:: bash + + $ openstack user role add demo --user heat-user --project heat + +``role remove`` +--------------- + +positional arguments:: + + Role name or ID to remove from user + +optional arguments:: + + --project Project to include (name or ID) + --user Name or ID of user + + +example: + +.. code-block:: bash + + $ openstack user role remove demo --user heat-user --project heat + +-------- +Services +-------- + +``service create`` +------------------ + +positional arguments:: + + New service name + +optional arguments:: + + --type New service type (compute, image, identity, volume, etc) + --description New service description + +example: + +.. code-block:: bash + + $ openstack service create nova --type compute --description "Nova Compute Service" + +``service list`` +---------------- + +optional arguments:: + + --long List additional fields in output + +example: + +.. code-block:: bash + + $ openstack service list + +``service show`` +---------------- + +positional arguments:: + + Service to display (type, name or ID) + +example: + +.. code-block:: bash + + $ openstack service show nova + +``service delete`` +------------------ + +positional arguments:: + + Service to delete (name or ID) + +example: + +.. code-block:: bash + + $ openstack service delete nova + + +Using python-keystoneclient (v2.0) +================================== + ------- Tenants ------- -Tenants are the high level grouping within Keystone that represent groups of -users. A tenant is the grouping that owns virtual machines within Nova, or -containers within Swift. A tenant can have zero or more users, Users can be -associated with more than one tenant, and each tenant - user pairing can have -a role associated with it. - ``tenant-create`` ----------------- @@ -112,7 +592,7 @@ example: $ keystone user-list ``user-update`` ---------------- +--------------------- arguments diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst index b41337a5ec..bd2c914d53 100644 --- a/doc/source/configuration.rst +++ b/doc/source/configuration.rst @@ -315,28 +315,27 @@ configuration option. The drivers Keystone provides are: -* ``keystone.token.persistence.backends.sql.Token`` - The SQL-based (default) - token persistence engine. This backend stores all token data in the same SQL - store that is used for Identity/Assignment/etc. - -* ``keystone.token.persistence.backends.memcache.Token`` - The memcached based - token persistence backend. This backend relies on ``dogpile.cache`` and stores - the token data in a set of memcached servers. The servers urls are specified - in the ``[memcache]\servers`` configuration option in the Keystone config. - * ``keystone.token.persistence.backends.memcache_pool.Token`` - The pooled memcached token persistence engine. This backend supports the concept of pooled memcache client object (allowing for the re-use of the client objects). This backend has a number of extra tunable options in the ``[memcache]`` section of the config. +* ``keystone.token.persistence.backends.sql.Token`` - The SQL-based (default) + token persistence engine. + +* ``keystone.token.persistence.backends.memcache.Token`` - The memcached based + token persistence backend. This backend relies on ``dogpile.cache`` and stores + the token data in a set of memcached servers. The servers URLs are specified + in the ``[memcache]\servers`` configuration option in the Keystone config. + .. WARNING:: It is recommended you use the ``keystone.token.persistence.backend.memcache_pool.Token`` backend instead of ``keystone.token.persistence.backend.memcache.Token`` as the token persistence driver if you are deploying Keystone under eventlet instead of - Apache + mod_wsgi. This recommendation are due to known issues with the use of - ``thread.local`` under eventlet that can allow the leaking of memcache client objects - and consumption of extra sockets. + Apache + mod_wsgi. This recommendation is due to known issues with the + use of ``thread.local`` under eventlet that can allow the leaking of + memcache client objects and consumption of extra sockets. Token Provider @@ -650,9 +649,9 @@ To build your service catalog using this driver, see the built-in help: .. code-block:: bash - $ keystone - $ keystone help service-create - $ keystone help endpoint-create + $ openstack --help + $ openstack help service create + $ openstack help endpoint create You can also refer to `an example in Keystone (tools/sample_data.sh) `_. @@ -666,8 +665,7 @@ service catalog will not change very much over time. .. NOTE:: - Attempting to manage your service catalog using keystoneclient commands - (e.g. ``keystone endpoint-create``) against this driver will result in + Attempting to change your service catalog against this driver will result in ``HTTP 501 Not Implemented`` errors. This is the expected behavior. If you want to use these commands, you must instead use the SQL-based Service Catalog driver. @@ -1014,12 +1012,12 @@ Ensure that your ``keystone.conf`` is configured to use a SQL driver: [identity] driver = keystone.identity.backends.sql.Identity -You may also want to configure your ``[sql]`` settings to better reflect your +You may also want to configure your ``[database]`` settings to better reflect your environment: .. code-block:: ini - [sql] + [database] connection = sqlite:///keystone.db idle_timeout = 200 @@ -1038,23 +1036,19 @@ You should now be ready to initialize your new database without error, using: $ keystone-manage db_sync To test this, you should now be able to start ``keystone-all`` and use the -Keystone Client to list your tenants (which should successfully return an +OpenStack Client to list your projects (which should successfully return an empty list from your new database): .. code-block:: bash - $ keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ tenant-list - +----+------+---------+ - | id | name | enabled | - +----+------+---------+ - +----+------+---------+ + $ openstack --os-token ADMIN --os-url http://127.0.0.1:35357/v2.0/ project list .. NOTE:: - We're providing the default OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT values - from ``keystone.conf`` to connect to the Keystone service. If you changed - those values, or deployed Keystone to a different endpoint, you will need - to change the provided command accordingly. + We're providing the default OS_TOKEN and OS_URL values from ``keystone.conf`` + to connect to the Keystone service. If you changed those values, or deployed + Keystone to a different endpoint, you will need to change the provided + command accordingly. Initializing Keystone ===================== @@ -1079,12 +1073,29 @@ prevents unauthorized users from spuriously signing tokens. be running the Keystone service to ensure proper ownership for the private key file and the associated certificates. -Adding Users, Tenants, and Roles with python-keystoneclient -=========================================================== +Adding Users, Projects, and Roles via Command Line Interfaces +============================================================= -Users, tenants, and roles must be administered using admin credentials. -There are two ways to configure ``python-keystoneclient`` to use admin -credentials, using the either an existing token or password credentials. +Keystone APIs are protected by the rules in the policy file. The default policy +rules require admin credentials to administer ``users``, ``projects``, and +``roles``. See section `Keystone API protection with Role Based Access Control (RBAC)`_ +for more details on policy files. + +The Keystone command line interface packaged in `python-keystoneclient`_ only +supports the Identity v2.0 API. The OpenStack common command line interface +packaged in `python-openstackclient`_ supports both v2.0 and v3 APIs. + +With both command line interfaces there are two ways to configure the client to +use admin credentials, using either an existing token or password credentials. + +.. NOTE:: + + As of the Juno release, it is recommended to use ``python-openstackclient``, + as it supports both v2.0 and v3 APIs. For the purpose of backwards compatibility, + the CLI packaged in ``python-keystoneclient`` is not being removed. + +.. _`python-openstackclient`: http://docs.openstack.org/developer/python-openstackclient/ +.. _`python-keystoneclient`: http://docs.openstack.org/developer/python-keystoneclient/ Authenticating with a Token --------------------------- @@ -1094,11 +1105,11 @@ Authenticating with a Token If your Keystone deployment is brand new, you will need to use this authentication method, along with your ``[DEFAULT] admin_token``. -To use Keystone with a token, set the following flags: +To authenticate with Keystone using a token and ``python-openstackclient``, set +the following flags. -* ``--os-endpoint OS_SERVICE_ENDPOINT``: allows you to specify the Keystone endpoint - to communicate with. The default endpoint is ``http://localhost:35357/v2.0`` -* ``--os-token OS_SERVICE_TOKEN``: your service token +* ``--os-url OS_URL``: Keystone endpoint the user communicates with +* ``--os-token OS_TOKEN``: User's service token To administer a Keystone endpoint, your token should be either belong to a user with the ``admin`` role, or, if you haven't created one yet, should be equal to @@ -1109,20 +1120,27 @@ to be passed as arguments each time: .. code-block:: bash - $ export OS_SERVICE_ENDPOINT=http://localhost:35357/v2.0 - $ export OS_SERVICE_TOKEN=ADMIN + $ export OS_URL=http://localhost:35357/v2.0 + $ export OS_TOKEN=ADMIN + +Instead of ``python-openstackclient``, if using ``python-keystoneclient``, +set the following: + +* ``--os-endpoint OS_SERVICE_ENDPOINT``: equivalent to ``--os-url OS_URL`` +* ``--os-service-token OS_SERVICE_TOKEN``: equivalent to ``--os-token OS_TOKEN`` + Authenticating with a Password ------------------------------ -To administer a Keystone endpoint, the following user referenced below should +To authenticate with Keystone using a password and ``python-openstackclient``, set +the following flags, note that the following user referenced below should be granted the ``admin`` role. -* ``--os_username OS_USERNAME``: Name of your user -* ``--os_password OS_PASSWORD``: Password for your user -* ``--os_tenant_name OS_TENANT_NAME``: Name of your tenant -* ``--os_auth_url OS_AUTH_URL``: URL of your Keystone auth server, e.g. - ``http://localhost:35357/v2.0`` +* ``--os-username OS_USERNAME``: Name of your user +* ``--os-password OS_PASSWORD``: Password for your user +* ``--os-project-name OS_PROJECT_NAME``: Name of your project +* ``--os-auth-url OS_AUTH_URL``: URL of the Keystone authentication server You can also set these variables in your environment so that they do not need to be passed as arguments each time: @@ -1131,42 +1149,55 @@ to be passed as arguments each time: $ export OS_USERNAME=my_username $ export OS_PASSWORD=my_password - $ export OS_TENANT_NAME=my_tenant + $ export OS_PROJECT_NAME=my_project + $ export OS_AUTH_URL=http://localhost:35357/v2.0 + +If using ``python-keystoneclient``, set the following instead: + +* ``--os-tenant-name OS_TENANT_NAME``: equivalent to ``--os-project-name OS_PROJECT_NAME`` + Example usage ------------- -``keystone`` is set up to expect commands in the general form of -``keystone`` ``command`` ``argument``, followed by flag-like keyword arguments to -provide additional (often optional) information. For example, the command -``user-list`` and ``tenant-create`` can be invoked as follows: +``python-openstackclient`` is set up to expect commands in the general form of: .. code-block:: bash - # Using token auth env variables - $ export OS_SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0/ - $ export OS_SERVICE_TOKEN=secrete_token - $ keystone user-list - $ keystone tenant-create --name=demo + $ openstack [] [] [] - # Using token auth flags - $ keystone --os-token=secrete --os-endpoint=http://127.0.0.1:35357/v2.0/ user-list - $ keystone --os-token=secrete --os-endpoint=http://127.0.0.1:35357/v2.0/ tenant-create --name=demo +For example, the commands ``user list`` and ``project create`` can be invoked +as follows: - # Using user + password + tenant_name env variables +.. code-block:: bash + + # Using token authentication, with environment variables + $ export OS_URL=http://127.0.0.1:35357/v2.0/ + $ export OS_TOKEN=secrete_token + $ openstack user list + $ openstack project create demo + + # Using token authentication, with flags + $ openstack --os-token=secrete --os-url=http://127.0.0.1:35357/v2.0/ user list + $ openstack --os-token=secrete --os-url=http://127.0.0.1:35357/v2.0/ project create demo + + # Using password authentication, with environment variables $ export OS_USERNAME=admin $ export OS_PASSWORD=secrete - $ export OS_TENANT_NAME=admin - $ keystone user-list - $ keystone tenant-create --name=demo + $ export OS_PROJECT_NAME=admin + $ export OS_AUTH_URL=http://localhost:35357/v2.0 + $ openstack user list + $ openstack project create demo - # Using user + password + tenant_name flags - $ keystone --os_username=admin --os_password=secrete --os_tenant_name=admin user-list - $ keystone --os_username=admin --os_password=secrete --os_tenant_name=admin tenant-create --name=demo + # Using password authentication, with flags + $ openstack --os-username=admin --os-password=secrete --os-project-name=admin --os-auth-url=http://localhost:35357/v2.0 user list + $ openstack --os-username=admin --os-password=secrete --os-project-name=admin --os-auth-url=http://localhost:35357/v2.0 project create demo -For additional examples refer to `CLI Examples`_. +For additional examples using ``python-keystoneclient`` refer to `python-keystoneclient examples`_, +likewise, for additional examples using ``python-openstackclient``, refer to `python-openstackclient examples`_. -.. _`CLI Examples`: cli_examples.html +.. _`python-keystoneclient examples`: cli_examples.html#using-python-keystoneclient-v2-0 +.. _`python-openstackclient examples`: cli_examples.html#using-python-openstackclient-v3 Removing Expired Tokens diff --git a/doc/source/configuringservices.rst b/doc/source/configuringservices.rst index 7509af148a..d14d058231 100644 --- a/doc/source/configuringservices.rst +++ b/doc/source/configuringservices.rst @@ -32,7 +32,7 @@ In general: * The Keystone middleware will look for and validate that token, taking the appropriate action. * It will also retrieve additional information from the token such as user - name, id, tenant name, id, roles, etc... + name, user id, project name, project id, roles, etc... The middleware will pass those data down to the service as headers. More details on the architecture of that setup is described in @@ -57,10 +57,10 @@ represent a user, and carries no explicit authorization. To disable in production (highly recommended), remove AdminTokenAuthMiddleware from your paste application pipelines (for example, in keystone-paste.ini) -Setting up tenants, users, and roles ------------------------------------- +Setting up projects, users, and roles +------------------------------------- -You need to minimally define a tenant, user, and role to link the tenant and +You need to minimally define a project, user, and role to link the project and user as the most basic set of details to get other services authenticating and authorizing with Keystone. @@ -69,7 +69,7 @@ be able to use to authenticate users against Keystone. The ``auth_token`` middleware supports using either the shared secret described above as `admin_token` or users for each service. -See :doc:`configuration` for a walk through on how to create tenants, users, +See :doc:`configuration` for a walk through on how to create projects, users, and roles. Setting up services @@ -79,53 +79,44 @@ Creating Service Users ---------------------- To configure the OpenStack services with service users, we need to create -a tenant for all the services, and then users for each of the services. We -then assign those service users an Admin role on the service tenant. This -allows them to validate tokens - and authenticate and authorize other user +a project for all the services, and then users for each of the services. We +then assign those service users an ``admin`` role on the service project. This +allows them to validate tokens - and to authenticate and authorize other user requests. -Create a tenant for the services, typically named 'service' (however, the +Create a project for the services, typically named ``service`` (however, the name can be whatever you choose): .. code-block:: bash - $ keystone tenant-create --name=service + $ openstack project create service -This returns a UUID of the tenant - keep that, you'll need it when creating -the users and specifying the roles. - -Create service users for nova, glance, swift, and neutron (or whatever -subset is relevant to your deployment): +Create service users for ``nova``, ``glance``, ``swift``, and ``neutron`` +(or whatever subset is relevant to your deployment): .. code-block:: bash - $ keystone user-create --name=nova \ - --pass=Sekr3tPass \ - --tenant_id=[the uuid of the tenant] \ - --email=nova@nothing.com + $ openstack user create nova --password Sekr3tPass --project service -Repeat this for each service you want to enable. Email is a required field -in Keystone right now, but not used in relation to the service accounts. Each -of these commands will also return a UUID of the user. Keep those to assign -the Admin role. +Repeat this for each service you want to enable. -For adding the Admin role to the service accounts, you'll need to know the UUID -of the role you want to add. If you don't have them handy, you can look it +Create an administrative role for the service accounts, typically named +``admin`` (however the name can be whatever you choose). For adding the +administrative role to the service accounts, you'll need to know the +name of the role you want to add. If you don't have it handy, you can look it up quickly with: .. code-block:: bash - $ keystone role-list + $ openstack role list -Once you have it, assign the service users to the Admin role. This is all -assuming that you've already created the basic roles and settings as described -in :doc:`configuration`: +Once you have it, grant the administrative role to the service users. This is +all assuming that you've already created the basic roles and settings as +described in :doc:`configuration`: .. code-block:: bash - $ keystone user-role-add --tenant_id=[uuid of the service tenant] \ - --user=[uuid of the service account] \ - --role=[uuid of the Admin role] + $ openstack role add admin --project service --user nova Defining Services ----------------- @@ -147,21 +138,16 @@ Keystone is online, you need to add the services to the catalog: .. code-block:: bash - $ keystone service-create --name=nova \ - --type=compute \ - --description="Nova Compute Service" - $ keystone service-create --name=ec2 \ - --type=ec2 \ - --description="EC2 Compatibility Layer" - $ keystone service-create --name=glance \ - --type=image \ - --description="Glance Image Service" - $ keystone service-create --name=keystone \ - --type=identity \ - --description="Keystone Identity Service" - $ keystone service-create --name=swift \ - --type=object-store \ - --description="Swift Service" + $ openstack service create nova --type compute \ + --description "Nova Compute Service" + $ openstack service create ec2 --type ec2 \ + --description "EC2 Compatibility Layer" + $ openstack service create glance --type image \ + --description "Glance Image Service" + $ openstack service create keystone --type identity \ + --description "Keystone Identity Service" + $ openstack service create swift --type object-store \ + --description "Swift Service" Setting Up Middleware @@ -209,9 +195,9 @@ Here is an example paste config filter that makes use of the 'admin_user' and admin_user = admin admin_password = keystone123 -It should be noted that when using this option an admin tenant/role -relationship is required. The admin user is granted access to the 'Admin' -role to the 'admin' tenant. +It should be noted that when using this option an admin project/role +relationship is required. The admin user is granted access to the 'admin' +role to the 'admin' project. The auth_token middleware can also be configured in nova.conf [keystone_authtoken] section to keep paste config clean of site-specific diff --git a/doc/source/extensions/shibboleth.rst b/doc/source/extensions/shibboleth.rst index 1f3a801398..97999d258a 100644 --- a/doc/source/extensions/shibboleth.rst +++ b/doc/source/extensions/shibboleth.rst @@ -45,7 +45,9 @@ file. You are advised to examine `Shibboleth Service Provider Configuration docu An example of your ``/etc/shibboleth/shibboleth2.xml`` may look like (The example shown below is for reference only, not to be used in a production -environment):: +environment): + +.. code-block:: xml