diff --git a/picketlink-federation-saml-idp-with-encryption/README.md b/picketlink-federation-saml-idp-with-encryption/README.md index c9af86e..85627e8 100644 --- a/picketlink-federation-saml-idp-with-encryption/README.md +++ b/picketlink-federation-saml-idp-with-encryption/README.md @@ -15,7 +15,7 @@ This example demonstrates the use of *PicketLink Federation* SAML v2.0 support t It provides a minimal configuration to enable your application as an Identity Provider, accordingly with the SAML v2.0 specification. An Identity Provider or IdP, is responsible to centralize authentication and issue SAML Assertions to their relying parties, also known as Service Providers. PicketLink supports both SAML v1.1 and v2.0 versions. -Although this example provides you a good start to understand how an Identity Provider works, it does not provide some other important security-related configurations such as signature and encryption. +Although this example provides you a good start to understand how an Identity Provider works, it does not provide some other important security-related configurations such as signature. We strongly recommend you to read our documentation about how to make your deployment safe and secure from a SAML perspective. Before you run this example, you must have a security-domain configuration in your server to authenticate users and provide role mappings. diff --git a/picketlink-federation-saml-idp-with-signature/README.md b/picketlink-federation-saml-idp-with-signature/README.md index f276a28..a7de476 100644 --- a/picketlink-federation-saml-idp-with-signature/README.md +++ b/picketlink-federation-saml-idp-with-signature/README.md @@ -15,7 +15,7 @@ This example demonstrates the use of *PicketLink Federation* SAML v2.0 support t It provides a minimal configuration to enable your application as an Identity Provider, accordingly with the SAML v2.0 specification. An Identity Provider or IdP, is responsible to centralize authentication and issue SAML Assertions to their relying parties, also known as Service Providers. PicketLink supports both SAML v1.1 and v2.0 versions. -Although this example provides you a good start to understand how an Identity Provider works, it does not provide some other important security-related configurations such as signature and encryption. +Although this example provides you a good start to understand how an Identity Provider works, it does not provide some other important security-related configurations such as encryption. We strongly recommend you to read our documentation about how to make your deployment safe and secure from a SAML perspective. Before you run this example, you must have a security-domain configuration in your server to authenticate users and provide role mappings. diff --git a/picketlink-federation-saml-idp-with-signature/conf/wildfly/WEB-INF/picketlink.xml b/picketlink-federation-saml-idp-with-signature/conf/wildfly/WEB-INF/picketlink.xml index 79b35d5..9485bcb 100644 --- a/picketlink-federation-saml-idp-with-signature/conf/wildfly/WEB-INF/picketlink.xml +++ b/picketlink-federation-saml-idp-with-signature/conf/wildfly/WEB-INF/picketlink.xml @@ -17,6 +17,7 @@ + diff --git a/picketlink-federation-saml-idp-with-ssl/README.md b/picketlink-federation-saml-idp-with-ssl/README.md index 908ddda..266d217 100644 --- a/picketlink-federation-saml-idp-with-ssl/README.md +++ b/picketlink-federation-saml-idp-with-ssl/README.md @@ -46,69 +46,12 @@ Configure Maven If you have not yet done so, you must [Configure Maven](http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/#configure_maven) before testing the quickstarts. -Create the Security Domain ---------------- - -These steps assume you are running the server in standalone mode and using the default standalone.xml supplied with the distribution. - -You configure the security domain by running JBoss CLI commands. For your convenience, this quickstart batches the commands into a `configure-security-domain.cli` script provided in the root directory of this quickstart. - -1. Before you begin, back up your server configuration file - * If it is running, stop the JBoss server. - * Backup the file: `JBOSS_HOME/standalone/configuration/standalone.xml` - * After you have completed testing this quickstart, you can replace this file to restore the server to its original configuration. - -2. Start the JBoss server by typing the following: - - For Linux: JBOSS_HOME/bin/standalone.sh - For Windows: JBOSS_HOME\bin\standalone.bat -3. Review the `configure-security-domain.cli` file in the root of this quickstart directory. This script adds the `idp` domain to the `security` subsystem in the server configuration and configures authentication access. Comments in the script describe the purpose of each block of commands. - -4. Open a new command prompt, navigate to the root directory of this quickstart, and run the following command, replacing JBOSS_HOME with the path to your server: - - JBOSS_HOME/bin/jboss-cli.sh --connect --file=configure-security-domain.cli -You should see the following result when you run the script: - - The batch executed successfully - { - "outcome" => "success", - } - - - -Review the Modified Server Configuration ------------------------------------ - -If you want to review and understand newly added XML configuration, stop the JBoss server and open the `JBOSS_HOME/standalone/configuration/standalone.xml` file. - -The following `idp` security-domain was added to the `security` subsystem. - - - - - - - - - - - - - - - - - -The configuration above defines a security-domain which will be used by the IdP to authenticate users. This is a very simple configuration, -using a JAAS LoginModule that reads users and their corresponding roles from properties files. Both properties files, *users.properties* -and *roles.properties* are located at *src/main/resources* directory. - -In a real world scenario your users and roles will not be located in properties files, but in LDAP, databases or whatever, depending -where your identity data is located. JBoss AS/EAP SSL Configuration ------------------------------------ +------------------------------ +You now have to build first the keystores your server will reference to. + The next steps require that you are able to execute the Java Keytool. You also need to make sure all commands are executed inside the following directory in your *JBoss Enterprise Application Platform 6* or *WildFly* installation: @@ -173,7 +116,8 @@ Now we need to export the client's certificate and create a truststore by import keytool -import -file client.cer -alias client -keystore client.truststore Now that we have our certificates/keystores properly configured, you need to change your server installation to enable ssl. -Add the following connector to the web subsystem: + +for *JBoss Enterprise Application Platform 6* add the following connector in the web subsystem: +for *WildFly*, add a security-realm + + + + + + + + + + + + +then a https listener in the undertow subsystem: + + + You can now restart your server and check if it is responding on: https://localhost:8443 If everything is ok, you will be asked to trust the server certificate. + +Create the Security Domain +-------------------------- + +These steps assume you are running the server in standalone mode and using the default standalone.xml supplied with the distribution. + +You configure the security domain by running JBoss CLI commands. For your convenience, this quickstart batches the commands into a `configure-security-domain.cli` script provided in the root directory of this quickstart. + +1. Before you begin, back up your server configuration file + * If it is running, stop the JBoss server. + * Backup the file: `JBOSS_HOME/standalone/configuration/standalone.xml` + * After you have completed testing this quickstart, you can replace this file to restore the server to its original configuration. + +2. Start the JBoss server by typing the following: + + For Linux: JBOSS_HOME/bin/standalone.sh + For Windows: JBOSS_HOME\bin\standalone.bat +3. Review the `configure-security-domain.cli` file in the root of this quickstart directory. This script adds the `idp` domain to the `security` subsystem in the server configuration and configures authentication access. Comments in the script describe the purpose of each block of commands. + +4. Open a new command prompt, navigate to the root directory of this quickstart, and run the following command, replacing JBOSS_HOME with the path to your server: + + JBOSS_HOME/bin/jboss-cli.sh --connect --file=configure-security-domain.cli +You should see the following result when you run the script: + + The batch executed successfully + { + "outcome" => "success", + } + + +Review the Modified Server Configuration +---------------------------------------- + +If you want to review and understand newly added XML configuration, stop the JBoss server and open the `JBOSS_HOME/standalone/configuration/standalone.xml` file. + +The following `idp` security-domain was added to the `security` subsystem. + + + + + + + + + + + + + + + + + +The configuration above defines a security-domain which will be used by the IdP to authenticate users. This is a very simple configuration, +using a JAAS LoginModule that reads users and their corresponding roles from properties files. Both properties files, *users.properties* +and *roles.properties* are located at *src/main/resources* directory. + +In a real world scenario your users and roles will not be located in properties files, but in LDAP, databases or whatever, depending +where your identity data is located. + Configure the client certificate in your browser ----------------------------------- @@ -246,7 +267,7 @@ _NOTE: The following build command assumes you have configured your Maven user s Access the application --------------------- -The application will be running at the following URL: . +The application will be running at the following URL: . The IdP is pre-configured with a default user, whose credentials are: diff --git a/picketlink-federation-saml-idp-with-ssl/conf/wildfly/WEB-INF/jboss-web.xml b/picketlink-federation-saml-idp-with-ssl/conf/wildfly/WEB-INF/jboss-web.xml new file mode 100644 index 0000000..11007f9 --- /dev/null +++ b/picketlink-federation-saml-idp-with-ssl/conf/wildfly/WEB-INF/jboss-web.xml @@ -0,0 +1,8 @@ + + + idp + + + idp-ssl + \ No newline at end of file diff --git a/picketlink-federation-saml-idp-with-ssl/src/main/resources/users.properties b/picketlink-federation-saml-idp-with-ssl/src/main/resources/users.properties new file mode 100644 index 0000000..19250ad --- /dev/null +++ b/picketlink-federation-saml-idp-with-ssl/src/main/resources/users.properties @@ -0,0 +1 @@ +tomcat=tomcat \ No newline at end of file diff --git a/picketlink-federation-saml-sp-post-with-signature/README.md b/picketlink-federation-saml-sp-post-with-signature/README.md index 6d84b3a..7d7eed2 100644 --- a/picketlink-federation-saml-sp-post-with-signature/README.md +++ b/picketlink-federation-saml-sp-post-with-signature/README.md @@ -15,7 +15,7 @@ This example demonstrates the use of *PicketLink Federation* SAML v2.0 support t It provides a minimal configuration to enable your application as a Service Provider, accordingly with the SAML v2.0 specification. A Service Provider is an application that participates in a Single Sign-On as a relying party. It relies on the Identity Provider to authenticate users and issue SAML Assertions, which will be used by the Service Provider to authenticate the user locally. -Although this example provides you a good start to understand how a Service Provider works, it does not provide some other important security-related configurations such as signature and encryption. +Although this example provides you a good start to understand how a Service Provider works, it does not provide some other important security-related configurations such encryption. We strongly recommend you to read our documentation about how to make your deployment safe and secure from a SAML perspective. Before you run this example, you must have a security-domain configuration in your server to authenticate users based on the SAML Assertion issued by the Identity Provider. diff --git a/picketlink-federation-saml-sp-post-with-signature/src/main/webapp/WEB-INF/picketlink.xml b/picketlink-federation-saml-sp-post-with-signature/src/main/webapp/WEB-INF/picketlink.xml index bf906e5..8d6c185 100644 --- a/picketlink-federation-saml-sp-post-with-signature/src/main/webapp/WEB-INF/picketlink.xml +++ b/picketlink-federation-saml-sp-post-with-signature/src/main/webapp/WEB-INF/picketlink.xml @@ -11,7 +11,8 @@ - + + diff --git a/picketlink-federation-saml-sp-post-with-ssl/README.md b/picketlink-federation-saml-sp-post-with-ssl/README.md index 1514249..285bf4c 100644 --- a/picketlink-federation-saml-sp-post-with-ssl/README.md +++ b/picketlink-federation-saml-sp-post-with-ssl/README.md @@ -166,7 +166,7 @@ _NOTE: The following build command assumes you have configured your Maven user s Access the application --------------------- -The application will be running at the following URL: . +The application will be running at the following URL: . *Note: A Service Provider alone is not very useful without an Identity Provider to authenticate users and issue SAML Assertions. Once you get this application deployed, please take a look at [About the PicketLink Federation Quickstarts](../README.md#about-the-picketlink-federation-quickstarts).* diff --git a/picketlink-federation-saml-sp-with-encryption/README.md b/picketlink-federation-saml-sp-with-encryption/README.md index f7aada1..daad959 100644 --- a/picketlink-federation-saml-sp-with-encryption/README.md +++ b/picketlink-federation-saml-sp-with-encryption/README.md @@ -15,7 +15,7 @@ This example demonstrates the use of *PicketLink Federation* SAML v2.0 support t It provides a minimal configuration to enable your application as a Service Provider, accordingly with the SAML v2.0 specification. A Service Provider is an application that participates in a Single Sign-On as a relying party. It relies on the Identity Provider to authenticate users and issue SAML Assertions, which will be used by the Service Provider to authenticate the user locally. -Although this example provides you a good start to understand how a Service Provider works, it does not provide some other important security-related configurations such as signature and encryption. +Although this example provides you a good start to understand how a Service Provider works, it does not provide some other important security-related configurations such as signature. We strongly recommend you to read our documentation about how to make your deployment safe and secure from a SAML perspective. Before you run this example, you must have a security-domain configuration in your server to authenticate users based on the SAML Assertion issued by the Identity Provider.