Merge pull request #79 from jenmalloy/mod_auth_mellon-update

Mod_auth_mellon changes ready for review
This commit is contained in:
Jen Malloy 2017-02-09 16:25:49 -05:00 committed by GitHub
commit 4d6456a7d2
8 changed files with 214 additions and 34 deletions

View file

@ -4,7 +4,7 @@
====== SAML SP Client Adapter Changes
Keycloak SAML SP Client Adapter now requires a specific endpoint, `/saml` to be registered with your IDP.
Keycloak SAML SP Client Adapter now requires a specific endpoint, `/saml` to be registered with your IdP.
The SamlFilter must also be bound to /saml in addition to any other binding it has.
This had to be done because SAML POST binding would eat the request input stream and this would be really bad for clients that relied on it.

View file

@ -1,5 +1,5 @@
===== RoleIdentifiers element
===== RoleIdentifiers Element
The `RoleIdentifiers` element defines what SAML attributes within the assertion received from the user should be used
as role identifiers within the Java EE Security Context for the user.
@ -15,7 +15,7 @@ as role identifiers within the Java EE Security Context for the user.
----
By default `Role` attribute values are converted to Java EE roles.
Some IDPs send roles via a `member` or `memberOf` attribute assertion.
Some IdPs send roles using a `member` or `memberOf` attribute assertion.
You can define one or more `Attribute` elements to specify which SAML attributes must be converted into roles.

View file

@ -1,10 +1,10 @@
[[_saml-sp-keys]]
===== SP Keys and Key elements
===== Service Provider Keys and Key Elements
If the IDP requires that the client application (SP) sign all of its requests and/or if the IDP will encrypt assertions, you must define the keys used to do this.
For client signed documents you must define both the private and public key or certificate that will be used to sign documents.
For encryption, you only have to define the private key that will be used to decrypt.
If the IdP requires that the client application (or SP) sign all of its requests and/or if the IdP will encrypt assertions, you must define the keys used to do this.
For client-signed documents you must define both the private and public key or certificate that is used to sign documents.
For encryption, you only have to define the private key that is used to decrypt it.
There are two ways to describe your keys.
They can be stored within a Java KeyStore or you can copy/paste the keys directly within `keycloak-saml.xml` in the PEM format.

View file

@ -1,7 +1,7 @@
===== SP Element
Here is the explanation of the SP element attributes
Here is the explanation of the SP element attributes:
[source,xml]
----
@ -16,7 +16,7 @@ Here is the explanation of the SP element attributes
----
entityID::
This is the identifier for this client.
The IDP needs this value to determine who the client is that is communicating with it. This setting is _REQUIRED_.
The IdP needs this value to determine who the client is that is communicating with it. This setting is _REQUIRED_.
sslPolicy::
This is the SSL policy the adapter will enforce.
@ -24,28 +24,28 @@ sslPolicy::
For `ALL`, all requests must come in via HTTPS.
For `EXTERNAL`, only non-private IP addresses must come over the wire via HTTPS.
For `NONE`, no requests are required to come over via HTTPS.
This settings is _OPTIONAL_. Default value is `EXTERNAL`.
This setting is _OPTIONAL_. Default value is `EXTERNAL`.
nameIDPolicyFormat::
SAML clients can request a specific NameID Subject format.
Fill in this value if you want a specific format.
It must be a standard SAML format identifier, i.e. `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`.
It must be a standard SAML format identifier: `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`.
This setting is _OPTIONAL_.
By default, no special format is requested.
forceAuthentication::
SAML clients can request that a user is re-authenticated even if they are already logged in at the IDP.
SAML clients can request that a user is re-authenticated even if they are already logged in at the IdP.
Set this to `true` to enable. This setting is _OPTIONAL_.
Default value is `false`.
isPassive::
SAML clients can request that a user is never asked to authenticate even if they are not logged in at the IDP.
SAML clients can request that a user is never asked to authenticate even if they are not logged in at the IdP.
Set this to `true` if you want this.
Do not use together with `forceAuthentication` as they are opposite. This setting is _OPTIONAL_.
Default value is `false`.
turnOffChangeSessionIdOnLogin::
The session id is changed by default on a successful login on some platforms to plug a security attack vector.
The session ID is changed by default on a successful login on some platforms to plug a security attack vector.
Change this to `true` to disable this. It is recommended you do not turn it off.
Default value is `false`.

View file

@ -1,6 +1,6 @@
==== Registering with an IDP
==== Registering with an Identity Provider
For each servlet based adapter, the endpoint you register for the assert consumer service url and and single logout service
must be the base url of your servlet application with `/saml` appended to it i.e. `$$https://example.com/contextPath/saml$$`
For each servlet-based adapter, the endpoint you register for the assert consumer service URL and and single logout service
must be the base URL of your servlet application with `/saml` appended to it, that is, `$$https://example.com/contextPath/saml$$`.

View file

@ -3,4 +3,4 @@
This document describes the Keycloak SAML client adapter and how it can be configured for a variety of platforms.
The Keycloak SAML client adapter is a standalone component that provides generic SAML 2.0 support for your web applications.
There are no Keycloak server extensions built into it.
As long as the IDP you are talking to supports standard SAML, the Keycloak SAML client adapter should be able to integrate with it.
As long as the Identity Provider (IdP) being communicated with supports standard SAML, the Keycloak SAML client adapter should be able to integrate with it.

View file

@ -10,8 +10,8 @@ you do not define security constraints in _web.xml_.
Instead you define a filter mapping using the {{book.project.name}} servlet filter adapter to secure the url patterns you want to secure.
NOTE: Backchannel logout works a bit differently than the standard adapters.
Instead of invalidating the http session it instead marks the session id as logged out.
There's just no way of arbitrarily invalidating an http session based on a session id.
Instead of invalidating the http session it instead marks the session ID as logged out.
There's just no way of arbitrarily invalidating an http session based on a session ID.
WARNING: Backchannel logout does not currently work when you have a clustered application that uses the SAML filter.
@ -43,7 +43,7 @@ You can define multiple filter mappings if you have various different secure and
WARNING: You must have a filter mapping that covers `/saml`.
This mapping covers all server callbacks.
When registering SPs with an IDP, you must register `http[s]://hostname/{context-root}/saml` as your Assert Consumer Service URL and Single Logout Service URL.
When registering SPs with an IdP, you must register `http[s]://hostname/{context-root}/saml` as your Assert Consumer Service URL and Single Logout Service URL.
To use this filter, include this maven artifact in your WAR poms:

View file

@ -2,24 +2,204 @@
=== mod_auth_mellon Apache HTTPD Module
The https://github.com/UNINETT/mod_auth_mellon[mod_auth_mellon] is an Apache HTTPD plugin for SAML. If your language/environment supports using Apache HTTPD
as a proxy, then you can use _mod_auth_mellon_ to secure your web application with SAML. Configuration of this adapter
is beyond the scope of this document. Please see the _mod_auth_mellon_ Github repo for more details on configuration.
The https://github.com/UNINETT/mod_auth_mellon[mod_auth_mellon] module is an Apache HTTPD plugin for SAML. If your language/environment supports using Apache HTTPD as a proxy, then you can use mod_auth_mellon to secure your web application with SAML. <do we still want to refer users to the github repo?>For more details on this module see the _mod_auth_mellon_ Github repo.
To configure _mod_auth_mellon_ you'll need
To configure mod_auth_mellon you'll need:
* IDP entity descriptor XML file. This describes the connection to {{book.project.name}} or another SAML IDP
* SP entity descriptor XML file. This describes the SAML connections and config for the application you are securing.
* Private key PEM file. This is a text file that defines the private key the application will use to sign documents. It is
in the PEM format
* Certificate PEM file. This is a text file that defines the certificate for your application.
* _mod_auth_mellon_ specific Apache HTTPD module config.
* An Identity Provider (IdP) entity descriptor XML file, which describes the connection to {{book.project.name}} or another SAML IdP
* An SP entity descriptor XML file, which describes the SAML connections and configuration for the application you are securing.
* A private key PEM file, which is a text file in the PEM format that defines the private key the application uses to sign documents.
* A certificate PEM file, which is a text file that defines the certificate for your application.
* mod_auth_mellon-specific Apache HTTPD module configuration.
If you have already defined and registered the client application within a realm on the {{book.project.name}} application server,
{{book.project.name}} can generate all the files you need except the Apache HTTPD module config.
Go to the `Installation` tab of your SAML client and select the `Mod Auth Mellon files` option.
{{book.project.name}} can generate all the files you need except the Apache HTTPD module configuration.
To generate the Apache HTTPD module configuration, complete the following steps:
. Go to the *Installation* page of your SAML client and select the *Mod Auth Mellon files* option.
+
.mod_auth_mellon config download
image:../../{{book.images}}/mod-auth-mellon-config-download.png[]
Click the `Download` button and you will download a zip file that contains the XML descriptor and pem files you need.
. Click *Download* to download a zip file that contains the XML descriptor and PEM files you need.
<How does the following content relate to the previous paragraph?>
==== Configuring mod_auth_mellon with Red Hat Single Sign-On
There are two hosts involved:
*The host on which Red Hat Single Sign-On is running, which will be referred to as $idp_host because Red Hat Single Sign-On is a SAML identity provider (IdP).
*The host on which the web application is running, which will be referred to as $sp_host. In SAML an application using an IdP is called a service provider (SP).
All of the following steps need to performed on $sp_host with root privileges.
===== Installing the Packages
To install the necessary packages, you will need:
* Apache Web Server (httpd)
* Mellon SAML SP add-on module for Apache
* Tools to create X509 certificates
To install the necessary packages, run this command:
`yum install httpd mod_auth_mellon mod_ssl openssl`
===== Creating a Configuration Directory for Apache SAML
It is advisable to keep configuration files related to Apache's use of SAML in one location.
Create a new directory named saml2 located under the Apache configuration root /etc/httpd:
`mkdir /etc/httpd/saml2`
===== Configuring the Mellon Service Provider
Configuration files for Apache add-on modules are located in the /etc/httpd/conf.d directory and have a file name extension of .conf. You need to create the /etc/httpd/conf.d/mellon.conf file and place Mellon's configuration directives in it.
Mellon's configuration directives can roughly be broken down into two classes of information:
* Which URLs to protect with SAML authentication
* What SAML parameters will be used when a protected URL is referenced.
Apache configuration directives typically follow a hierarchical tree structure in the URL space, which are known as locations. You need to specify one or more URL locations for Mellon to protect. You have flexibility in how you add the configuration parameters that apply to each location. You can either add all the necessary parameters to the location block or you can add Mellon parameters to a common location high up in the URL location hierarchy that specific protected locations inherit (or some combination of the two). Since it is common for an SP to operate in the same way no matter which location triggers SAML actions, the example configuration used here places common Mellon configuration directives in the root of the hierarchy and then specific locations to be protected by Mellon can be defined with minimal directives. This strategy avoids duplicating the same parameters for each protected location.
This example has just one protected location: https://$sp_host/protected.
To configure the Mellon service provider, complete the following steps:
. Create the file /etc/httpd/conf.d/mellon.conf with this content:
<Location / >
MellonEnable info
MellonEndpointPath /mellon/
MellonSPMetadataFile /etc/httpd/saml2/mellon_metadata.xml
MellonSPPrivateKeyFile /etc/httpd/saml2/mellon.key
MellonSPCertFile /etc/httpd/saml2/mellon.crt
MellonIdPMetadataFile /etc/httpd/saml2/idp_metadata.xml
</Location>
<Location /private >
AuthType Mellon
MellonEnable auth
Require valid-user
</Location>
Note: Some of the files referenced in the code above are created in later steps.
===== Creating the Service Provider Metadata
In SAML IdPs and SPs exchange SAML metadata, which is in XML format. The schema for the metadata is a standard, thus assuring participating SAML entities can consume each other's metadata. You need:
* Metadata for the IdP that the SP utilizes
* Metadata describing the SP provided to the IdP
One of the components of SAML metadata is X509 certificates. These certificates are used for two purposes:
* Sign SAML messages so the receiving end can prove the message originated from the expected party.
* Encrypt the message during transport (seldom used because SAML messages typically occur on TLS-protected transports)
You can use your own certificates if you already have a Certificate Authority (CA) or you can generate a self-signed certificate. For simplicity in this example a self-signed certificate is used.
Because Mellon's SP metadata must reflect the capabilities of the installed version of mod_auth_mellon, must be valid SP metadata XML, and must contain an X509 certificate (whose creation can be obtuse unless you are familiar with X509 certificate generation) the most expedient way to produce the SP metadata is to use a tool included in the mod_auth_mellon package (mellon_create_metadata.sh). The generated metadata can always be edited later because it is a text file. The tool also creates your X509 key and certificate.
SAML IdPs and SPs identify themselves using a unique name known as an EntityID. To use the Mellon metadata creation tool you need:
* The EntityID, which is typically the URL of the SP, and often the URL of the SP where the SP metadata can be retrieved
* The URL where SAML messages for the SP will be consumed, which Mellon calls the MellonEndPointPath.
To create the SP metadata, complete the following steps:
. Create a few helper shell variables:
+
fqdn=`hostname`
mellon_endpoint_url="https://${fqdn}/mellon"
mellon_entity_id="${mellon_endpoint_url}/metadata"
file_prefix="$(echo "$mellon_entity_id" | sed 's/[^A-Za-z.]/_/g' | sed 's/__*/_/g')"
. Invoke the Mellon metadata creation tool by running this command:
+
`/usr/libexec/mod_auth_mellon/mellon_create_metadata.sh $mellon_entity_id $mellon_endpoint_url`
. Move the generated files to their destination (referenced in the /etc/httpd/conf.d/mellon.conf file created above):
+
mv ${file_prefix}.cert /etc/httpd/saml2/mellon.crt
mv ${file_prefix}.key /etc/httpd/saml2/mellon.key
mv ${file_prefix}.xml /etc/httpd/saml2/mellon_metadata.xml
===== Adding the Mellon Service Provider to the Red Hat Single Sign-On Identity Provider
Assumption: The Red Hat Single Sign-On IdP has already been installed on the $idp_host.
Red Hat Single Sign-On supports multiple tenancy where all users, clients, and so on are grouped in what is called a realm. Each realm is independent of other realms. You can use an existing realm in your Red Hat Single Sign-On, but this example shows how to create a new realm called test_realm and use that realm.
All these operations are performed using the Red Hat Single Sign-On administration web console. You must have the admin username and password for $idp_host.
To complete the following steps:
. Open the Admin Console and log on by entering the admin username and password.
+
After logging into the admin console there will be an existing realm. When Red Hat Single Sign-On is first set up a root realm, master, is created by default. Any previously created realms are listed in the upper left corner of the admin console in a drop-down list.
. From the realm drop-down list select *Add realm*.
. In the Name field type `test_realm` and click *Create*.
====== Adding the Mellon Service Provider as a Client of the Realm
In Red Hat Single Sign-On SAML SPs are known as clients. To add the SP we must be in the Clients section of the realm.
. Click the Clients menu item on the left and click *Create* in the upper right corner to create a new client.
====== Adding the Mellon SP Client
To add the Mellon SP client, complete the following steps:
. Set the client protocol to SAML. From the Client Protocol drop down list, select *saml*.
. Provide the Mellon SP metadata file created above (/etc/httpd/saml2/mellon_metadata.xml). Depending on where your browser is running you might have to copy the SP metadata from $sp_host to the machine on which your browser is running so the browser can find the file.
. Click *Save*.
====== Editing the Mellon SP Client
There are several client configuration parameters we suggest setting:
* Ensure "Force POST Binding" is On.
* Add paosResponse to the Valid Redirect URIs list:
. Copy the postResponse URL in "Valid Redirect URIs" and paste it into the empty add text fields just below the "+".
. Change "postResponse" to "paosResponse". (The paosResponse URL is needed for SAML ECP.)
. Click *Save* at the bottom.
Many SAML SPs determine authorization based on a user's membership in a group. The Red Hat Single Sign-On IdP can manage user group information but it does not supply the user's groups unless the IdP is configured to supply it as a SAML attribute.
To configure the IdP to supply the user's groups as as a SAML attribute, complete the following steps:
. Click the Mappers tab of the client.
. In the upper right corner of the Mappers page, click *Create*.
. From the Mapper Type drop-down list select *Group list*.
. Set Name to "group list."
. Set the SAML attribute name to "groups."
. Click *Save.*
The remaining steps are performed on $sp_host.
====== Retrieving the Identity Provider Metadata
Now that you have created the realm on the IdP you need to retrieve the IdP metadata associated with it so the Mellon SP recognizes it. In the /etc/httpd/conf.d/mellon.conf file created previously, the MellonIdPMetadataFile is specified as /etc/httpd/saml2/idp_metadata.xml but until now that file has not existed on $sp_host. To get that file we will retrieve it from the IdP.
. Retrieve the file from the IdP by substituting $idp_host with the correct value:
curl -k -o /etc/httpd/saml2/idp_metadata.xml \
https://$idp_host/auth/realms/test_realm/protocol/saml/descriptor
+
Mellon is now fully configured.
. To run a syntax check for Apache configuration files:
apachectl configtest
+
Note: configtest is equivalent to the -t argument to apachectl. If the configuration test shows any errors, correct them before proceeding.
. Restart the Apache server:
systemctl restart httpd.service
You have now set up both Red Hat Single Sign-On as a SAML IdP in the test_realm and mod_auth_mellon as SAML SP protecting the URL $sp_host/protected (and everything beneath it) by authenticating against the $``$idp_host`` IdP.