Changes between Version 11 and Version 12 of Aaa


Ignore:
Timestamp:
Oct 12, 2010, 3:25:39 PM (14 years ago)
Author:
tim.bauge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Aaa

    v11 v12  
    1212=== Deployment ===
    1313The STS is provided as a web app, to be deployed in a servlet container. A number of configuration options need to be set by editing property files in the WAR file before deployment.
    14 ==== Getting the STS WAR file ====
    15 The STS WAR file can be downloaded from here: [wiki:trt-war AAA downloads page]
     14==== Getting the software components for the STS ====
     15* Apache Tomcat servlet container or equivalent
     16Instructions for setting up Apache Tomcat can be found [http://tomcat.apache.org/tomcat-6.0-doc/setup.html here].
     17* Keystore
     18The STS requires a JKS keystore that contains a private key. A keystore can be generated using the Java Keytool. Instructions [http://wiki.eclipse.org/Generating_a_Private_Key_and_a_Keystore here].
     19* STS WAR file
     20The STS WAR file can be downloaded from here: [wiki:trt-war AAA downloads page].
     21The WAR files should be first configured for the deployment setup (see below) and then deployed in the servlet container. For Tomcat, instructions are provided [http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html here] (see in particular the "Deployment on Tomcat startup" section).
     22==== STS Configuration ====
     23The WAR file contains 3 files which need configuring to run correctly on the target deployment platform. Each field requiring a deployment specific value has been identified with the string "REPLACE:". Other fields have been set to typical defaults which should satisfy most deployments. These can however be modified for advanced tuning of the STS. For more information contact TRT.
     24The WAR file is an archive containing object code, presentation templates and configuration files. The downloaded WAR file should therefore be opened (e.g. using [http://www.7-zip.org/ 7-zip]) to edit the following configuration files:
     25* sts.war/META-INF/maven/com.thalesresearch.sensei/sensei-sts-service/pom.xml
     26Configuration fields:
     27||= '''Field''' =||= '''Expected content''' =||
     28||hosted.sts.url||URL of STS. This will be the Tomcat server URL route suffixed with /STS||
     29||keystore.filepath||File path of keystore, as an absolute path||
     30||keystore.password||Keystore password, defined during the keystore deployement||
     31||key.alias||Key alias, obtained from ''__???__''||
     32||key.password||Key password, obtained from ''__???__''||
     33||partner.aaaservice.filepath||File path of AAA Service metadata. ''__how do you include multiple AAA services ???__''  This metadata is generated by ''__???__''||
     34||partner.sts1.filepath||File path of trusted STS metadata. This metadata is generated by ''__???__''||
     35||partner.sts2.filepath||File path of trusted STS metadata. This metadata is generated by ''__???__''||
     36Note that more partner STS can be added, with incremental numbers. This allows peering between STS, and can be removed for a stand alone STS.
     37* sts.war/WEB-INF/classes/trustedEntities/hostedStsMetadata.xml
     38Configuration fields:
     39||= '''Field''' =||= '''Expected content''' =||
     40||entityID=||add the URL of this STS after the =||
     41||ds:X509Certificate||encoded signing key of this STS (instructions on obtaining it [wiki:encoded_signing_key here]). Note this field appears twice in the file||
     42||Location=||add the URL of this STS between the = and the /. Note this field appears twice in the file||
     43* sts.war/WEB-INF/classes/metadata.properties
     44Configuration fields:
     45'''COPY THESE FROM ABOVE'''
     46||= '''Field''' =||= '''Expected content''' =||
     47||keystore.file||File path of keystore||
     48||keystore.pass||Keystore password||
     49||key.pass||Key password||
     50||key.alias||Key alias||
     51||partner.aaaservice.file||File path of AAA Service metadata||
     52||partner.sts1.file||File path of trusted STS metadata||
     53||partner.sts2.file||File path of trusted STS metadata||
     54
     55
     56
     57-----------------------------
     58----------------------------------
     59
     60
    1661==== Configure ====
    17 The WAR file is an archive containing object code, presentation templates and configuration files. The downloaded WAR file should therefore be opened (e.g. using [http://www.7-zip.org/ 7-zip]) to access the configuration files located in ???/WEB-INF.
     62 located in ???/WEB-INF.
    1863===== Setting up a keystore =====
    19 1. The STS requires a JKS keystore that contains a private key. This is the key that will be used to sign all SAML objects such as assertions. A keystore can be generated using the Java Keytool. Instructions [http://wiki.eclipse.org/Generating_a_Private_Key_and_a_Keystore here].
    20 1. The STS configuration must be changed to use the new keystore. This is done by changing the following properties in metadata.properties:
    21 ||=Property=||=Description=||
    22 ||keystore.file||Location of the keystore. Default is security/keystore.jks||
    23 ||keystore.pass||Keystore password||
    24 ||key.alias||Certificate alias to be used for signing objects||
    25 ||key.pass||Password for the certificate alias||
    26 Note that if you change the location of the keystore, you will also need to update the project’s POM so that the keystore is not filtered, as this will corrupt it.
    27 ===== Hosted STS Metadata =====
    28 The exchange of SAML metadata is the first stage in enabling SAML single sign-on. Entities that want to establish trust with the hosted STS will need to exchange metadata with the hosted STS. SAML metadata for the hosted STS can be generated by running the Junit test:
    29 {{{
    30 com.thalesresearch.sensei.sts.service.trustedentity.saml.SamlMetadataGeneratorTestManual
    31 }}}
    32 By default, the generated metadata will be written to the following location:
    33 {{{
    34 src/main/resources/trustedEntities/hostedStsMetadata.xml
    35 }}}
    36 The metadata can be configured by changing the following properties in ‘metadata.properties’
    37 ||=Property=||=Description=||
    38 ||hostedSts.url||URL of the hosted STS. Used for the entity ID of the hosted STS.||
    39 ||hostedSts.wantIdpMetadataOnly||Boolean that sets whether the generated metadata also contains the metadata for the hosted Service Provider (needed for proxying authentication)||
    40 ||hostedSts.wantAuthnRequestsSigned||Boolean that sets whether the hosted STS requires Authentication Requests to be signed||
    41 ||hostedSts.ssoServiceRedirectUrl||String that sets the URL to which Service Providers should send Authentication Requests using the Redirect binding||
    42 ||hostedSts.tokenProcessing||String that sets the full URI to which STSs should POST assertions||
    43 ||hostedSp.signsAuthnRequests||Boolean that sets whether the hosted Service Provider signs authentication requests||
    44 ||hostedSp.wantAssertionsSigned||Boolean that sets whether the hosted Service Provider requires assertions to be signed||
    45 ||hostedSp.assertionConsumerUrl||String that sets the URL to which STSs should POST assertions||
    46 ===== Trusted Entity Register =====
    47 The Trusted Entity Register contains the metadata for all trusted Service Providers and trusted STSs. It is configured in the metadataProvider bean in applicationContext.xml.
    48 To register a trusted entity, you will need the metadata for that entity either in a file or as a URL. Files containing metadata should be stored in src/main/resources/trustedEntities. Configure a bean for the entity using the org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider class for metadata contained in a file or the org.opensaml.saml2.metadata.provider.HTTPMetadataProvider class for metadata as a URL.
    49 In addition to holding the metadata for trusted entities, the Trusted Entity Register also contains the entity ID of the hosted STS. By default, the entity ID of the hosted STS is the same as the name used for creating the metadata for the hosted STS.
    50 ===== Login properties =====
    51 The following table lists properties in login.properties that can be used to customise the login process.
    52 ||=Property=||=Description=||
    53 ||loginForm.url||Sets the location of the login form. The default is senseiLogin.jsp, which is located in src/main/webapp||
    54 ||authFilter.url||Sets the URL that the login page should POST authentication requests to||
    55 ||success.url||Default page that successfully authenticated users will be sent to.||
    56 ||failure.url||Default page that users will be sent to if authentication fails||
    57 The default login page, senseiLogin.jsp, can be easily customised. All of the labels are set in the messages.properties file in src/main/resources. The images used are located in src/main/webapp/images and can be replaced to customise the images displayed on the login page.
    58 ==== Build ====
    59 Once the STS has been configured, the application can be built using Maven by typing “mvn package”.
    60 All dependencies are located in the following repositories:
    61 * http://shibboleth.internet2.edu/downloads/maven2/
    62 * http://repo1.maven.org/maven2/
    63 The WAR file can then be deployed in a Java application server or container, such as Apache Tomcat.
    64 The STS is now ready. You can test login at /REST/SSO/login.
     64
    6565=== User administration ===
    6666The User Register contains user account data relating to users and their roles. It is configured in applicationContext-security.xml.