Style updates.

doc/integration/omniauth.md

@@ -41,11 +41,13 @@ that are in common for all providers that we need to consider.
 - `block_auto_created_users` defaults to `true`. If `true` auto created users will
   be blocked by default and will have to be unblocked by an administrator before
   they are able to sign in.
-- **Note:** If you set `block_auto_created_users` to `false`, make sure to only
-  define providers under `allow_single_sign_on` that you are able to control, like
-  SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
-  the Internet will be able to successfully sign in to your GitLab without
-  administrative approval.
+
+>**Note:**
+If you set `block_auto_created_users` to `false`, make sure to only
+define providers under `allow_single_sign_on` that you are able to control, like
+SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
+the Internet will be able to successfully sign in to your GitLab without
+administrative approval.
 
 To change these settings:
 
@@ -57,11 +59,16 @@ To change these settings:
     sudo editor /etc/gitlab/gitlab.rb
     ```
 
-    and change
+    and change:
 
     ```ruby
     gitlab_rails['omniauth_enabled'] = true
-    gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter'] # add providers that should be allowed to auto create accounts
+
+    # CAUTION!
+    # This allows users to login without having a user account first. Define the allowed providers
+    # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
+    # User accounts will be created automatically when authentication was successful.
+    gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter']
     gitlab_rails['omniauth_block_auto_created_users'] = true
     ```
 
@@ -75,7 +82,7 @@ To change these settings:
     sudo -u git -H editor config/gitlab.yml
     ```
 
-    and change the following section
+    and change the following section:
 
     ```yaml
      ## OmniAuth settings
@@ -99,7 +106,7 @@ the configuration process.
 ## Enable OmniAuth for an Existing User
 
 Existing users can enable OmniAuth for specific providers after the account is
-created. For example, if the user originally signed in with LDAP an OmniAuth
+created. For example, if the user originally signed in with LDAP, an OmniAuth
 provider such as Twitter can be enabled. Follow the steps below to enable an
 OmniAuth provider for an existing user.
 
@@ -112,7 +119,10 @@ OmniAuth provider for an existing user.
 
 The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on.
 
-## Using Custom Omniauth Providers (only works on installations from source)
+## Using Custom Omniauth Providers
+
+>**Note:**
+The following information only applies for installations from source.
 
 GitLab uses [Omniauth](http://www.omniauth.org/) for authentication and already ships
 with a few providers pre-installed (e.g. LDAP, GitHub, Twitter). But sometimes that

doc/integration/saml.md

@@ -97,33 +97,33 @@ in your SAML IdP:
         }
     ```
 
-1.  Change the value for 'assertion_consumer_service_url' to match the HTTPS endpoint
-    of GitLab (append 'users/auth/saml/callback' to the HTTPS URL of your GitLab
+1.  Change the value for `assertion_consumer_service_url` to match the HTTPS endpoint
+    of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
     installation to generate the correct value).
 
-1.  Change the values of 'idp_cert_fingerprint', 'idp_sso_target_url',
-    'name_identifier_format' to match your IdP. Check
+1.  Change the values of `idp_cert_fingerprint`, `idp_sso_target_url`,
+    `name_identifier_format` to match your IdP. Check
     [the omniauth-saml documentation](https://github.com/omniauth/omniauth-saml)
     for details on these options.
 
-1.  Change the value of 'issuer' to a unique name, which will identify the application
+1.  Change the value of `issuer` to a unique name, which will identify the application
     to the IdP.
 
 1.  Restart GitLab for the changes to take effect.
 
 1.  Register the GitLab SP in your SAML 2.0 IdP, using the application name specified
-    in 'issuer'.
+    in `issuer`.
 
 To ease configuration, most IdP accept a metadata URL for the application to provide
 configuration information to the IdP. To build the metadata URL for GitLab, append
-'users/auth/saml/metadata' to the HTTPS URL of your GitLab installation, for instance:
+`users/auth/saml/metadata` to the HTTPS URL of your GitLab installation, for instance:
    ```
    https://gitlab.example.com/users/auth/saml/metadata
    ```
 
 At a minimum the IdP *must* provide a claim containing the user's email address, using
-claim name 'email' or 'mail'. The email will be used to automatically generate the GitLab
-username. GitLab will also use claims with name 'name', 'first_name', 'last_name'
+claim name `email` or `mail`. The email will be used to automatically generate the GitLab
+username. GitLab will also use claims with name `name`, `first_name`, `last_name`
 (see [the omniauth-saml gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
 for supported claims).
 
@@ -137,7 +137,7 @@ If you see a "500 error" in GitLab when you are redirected back from the SAML si
 this likely indicates that GitLab could not get the email address for the SAML user.
 
 Make sure the IdP provides a claim containing the user's email address, using claim name
-'email' or 'mail'. The email will be used to automatically generate the GitLab username.
+`email` or `mail`.
 
 If after signing in into your SAML server you are redirected back to the sign in page and
 no error is displayed, check your `production.log` file. It will most likely contain the