Advanced Customization

Please request/suggest additional topics via the FR discussion list.

Integrating reporting from your federations data sources

With Federation Registry 1.2 reporting becomes a key part of the deliverable for Federation wide administrators, IdP administrators and SP administrators.

Due to the unique nature of each federation however we provide no solution for populating the reporting data from your discovery services, IdP or SP. There are many methods that could be employed to achieve this collection.

Once you have decided how to collect relevant data injecting it to the FR reporting engine is simplistic:
1. Locate the table wayf_access_record in your database
2. For each relevant authentication event create a new row providing all data except the id and version fields (these are automatically populated) as follows:
    insert into wayf_access_record (date_created, ds_host, idpid, request_type, robot, source, spid) values (curdate(), '', 1, 'DS', false, '', 22);

This indicates that a machine named accessed the service with internal FR ID 22 via the DS at the current date and authenticated with the IDP with internal FR ID 1.

The AAF for example is currently collecting this data through our DS logs. In the future we intend to move directly to collecting this information from IdP audit logs.

Adding support for third party Certifying Authorities (CA)

The certificates that Federation Registry works with are those which are directly used to sign/encrypt SAML assertions. For users of the Shibboleth IdP this is the same certificate that is use when performing requests to SAML endpoints that are bound to port 8443 on your server.

For the most part the AAF and other major federations recommend using self signed certificates for this process. The Incommon folks summarize our position on this well:

In the base SAML metadata specification [1], a certificate signing authority (CA) has no assumed relevance to the trust model that secures the interactions among a federation's participants. In fact, certificates signed by a CA are discouraged since they can create interoperability issues in certain situations and lead to configurations that mistakenly establish trust based on the certificate signer. Allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not enrolled in the Federation.

However in certain situations IdP or SP may have some external requirement to provide a certificate that is signed by a third party CA. If this is the case then Federation Registry and subsequently other federation components must be able to validate the entire chain.

To facilitate this process all components of the CA chain including intermediaries must be configured through Federation Registry. Once stored these certificates are:
1. Used in order to validate new certificates for IdP and SP
2. Published to the generated metadata document for your federation

To assist with this process a script has been provided (currently in the develop branch but will appear in master as part of FR release after 1.1.3)

As a Federation Registry administrator access your instance and navigate to the console tab. Copy the script provided into the console. For each CA you wish to store in Federation Registry copy the script data where indicated and then execute. To permanently commit the certificate ensure the value for commit is set to true.

Here is an example of the script in use with a populated CA:

import fedreg.core.*

Allows FR administrators to import third party CA for validating signed certificates supplied
by IdP or SP (it is recommended they use self signed but this is not always practical)

Be sure to import all certificates in the chain, intermediatries can be particuarly tricky.
Until the chain is complete FR will continue to fail in verifying certificates

Bradley Beddoes

def commit true

def data """-----BEGICERTIFICATE-----
-----END CERTIFICATE-----"""

// ---------------------------
// ---------------------------


def caCert new CACertificate(data:data)
def caKeyInfo new CAKeyInfo(certificate:caCert)

    println "ErroimportinCA"
    caKeyInfo.errors.each {println it}
      println "Cimportesuccessfully"

Adding to federation-administrators group for federation level workflow approvals

The following will provide additional folks in your federation management team with the ability to receive emails to approve workflow actions on behalf of the entire federation. Adding users to this role will not however give them administrative control over individual components within your federation.

To add a user:
  1. Click on 'Access Control' in the top navigation menu
  2. Click on 'Roles'
  3. Enter "federation-administrators" into the filter
  4. Click view
  5. Click members
  6. Click Add Members
  7. Ensure 'Users' has the radio button
  8. Search for the new users on Name, Username or email
  9. Click 'Add'
  10. Repeat for additional users.
  11. Once finished the listed users will receive and be able to approve/reject workflow items that apply to federation as a whole.
We recommend you keep this group relatively small generally not many folks have the right to decide about actions that impact the entire federation.

Adding global administrators

Global administrators are able to make changes to anything being managed by Federation Registry, execute code in the Federation Registry console and modify roles, users and grant global admin status to other users. Audit this group carefully.

To add a global administrator:
  1. Click on 'Access Control' in the top navigation menu
  2. Click on 'Admins'
  3. Search for the new users on Name, Username or email
  4. Click 'Grant'
  5. Repeat for additional users as required

Importing from an existing Switch Resource Registry

We've attempted to provide some support for this process but it may be tricky depending on your setup, customizations and other factors.

Follow the process for installation until you reach the requirement to use scripts/setup/createBaseEnvironment.groovy and stop at that point.

In the directory scripts/rr-helpers you'll notice several files. The core one being importRRContent.groovy. You'll need to review this script and understand what it is doing to continue and it will require configuration for a read-only account to access your current RR database.

Each of the major operations are commented out by default. Our suggestion is you uncomment and execute one at a time ensuring you get no errors. In many cases you'll want to run this process a number of times in your development environment to customize for your RR dataset and any irregularities you may have.

Other scripts in the rr-helpers directory can help you extract details such as your current attribute set and supported CA set from the existing Resource Registry deployment, again much care will be required here.