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(), 'ds.aaf.edu.au', 1, 'DS', false, 'bradley-machine.at.home.com', 22);

This indicates that a machine named bradley-machine.at.home.com accessed the service with internal FR ID 22 via the DS ds.aaf.edu.au 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)
https://github.com/ausaccessfed/federationregistrymaster/blob/develop/scripts/administrative/importCA.groovy

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
25/03/2011
*/

def commit true

def data """-----BEGICERTIFICATE-----
MIIEvzCCBCigAwIBAgIQQZGhWjl4389JZWY4HUx1wjANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDQwNzE2MDAwMDAwWhcNMTQwNzE1MjM1OTU5WjCBtDELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNDEuMCwGA1UEAxMlVmVyaVNpZ24gQ2xhc3Mg
MyBDb2RlIFNpZ25pbmcgMjAwNCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAL687rx+74Pr4DdP+wMQOL4I0ox9nfqSfxkMwmvuQlKM3tMcSBMl6sFj
evlRZe7Tqjv18JScK/vyZtQk2vf1n24ZOTa80KN2CB4iJyRsOJEn4oRJrhuKof0l
giwQMOhxqyjod0pR8ezN+PBU1G/A420Kj9nYZI1jsi1OJ/aFDv5t4ymZ4oVHfC2G
f+hXj61nwjMykRMg/KkjFJptwoRLdmgE1XEsXSH6iA0m/R8tkSvnAVVN8m01KILf
2WtcttbZqoH9X82DumOd0CL8qTtCabKOOrW8tJ4PXsTqLIKLKP1TCJbdtQEg0fml
GOfA7lFwN+G2BUhSSG846sPobHtEhLsCAwEAAaOCAaAwggGcMBIGA1UdEwEB/wQI
MAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDEGA1UdHwQqMCgwJqAkoCKG
IGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDAzAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4QgEBBAQD
AgABMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFDbGFzczNDQTIwNDgtMS00MzAd
BgNVHQ4EFgQUCPVR6Pv+PT1kNnxoz1t4qN+5xTcwgYAGA1UdIwR5MHehY6RhMF8x
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMu
Q2xhc3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIQ
cLrkHRDZKTS2OMp7A8y6vzANBgkqhkiG9w0BAQUFAAOBgQCuOhe4SntV+mRV7ECk
7UlBkJmcibyvLh3KeCP5HBkPf+tovDLZiDje3D/TibQ/sYKW8aRauu0uJtPefAFu
AAoApAaSEUgJQPkcGHlnIyTgu9XhUK4b9Q7d4C6BzYCjbFJPkXVViroi8tLqQXWI
L2NVfR5UWpVZytk0gcBfXvZ6tQ==
-----END CERTIFICATE-----"""

// ---------------------------
// NO CHANGES BELOW THIS POINT
// ---------------------------

if(!commit)
   println "SCRIPRUNNININOCOMMIMODEUPDATENOPERMANENT\n"

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

if(commit{
  caKeyInfo.save()
  if(caKeyInfo.hasErrors(){
    println "ErroimportinCA"
    caKeyInfo.errors.each {println it}
  
  else 
      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.
Comments