Resource Integration Techniques

Go back

The following resource integration profiles are based on common categories of resources and applications. Their purpose is to help resource owners better understand the level of effort required to federation-enable specific types of resources. Note that a specific resource may or may not fit neatly into a specific integration profile. The intent of this section is not to prescribe an exhaustive set of resource integration techniques, but rather to provide enough detail about the critical differences between the techniques to illuminate the important issues that must be addressed when considering their use.

Technique 1: GFIPM-Aware Reverse Proxy and HTML Rewriting Service with No Secondary Authorization

Integration Technique 1 works best for a resource that meets the following criteria:

• It is not natively GFIPM-aware.
• It does not require local user accounts or user authentication as a prerequisite to access.
• It does not require or have any notion of intersession persistence or personalization.
• It cannot be modified at the source code level because of business/technical impracticalities.

In this integration technique, access to the resource is provided for federation members via network configuration by a reverse proxy service that is GFIPM-aware. Also, the proxy service must implement access control and auditing if they are required by the application.

Technique 2: GFIPM-Aware Reverse Proxy and HTML Rewriting Service with Secondary Authorization

Integration Technique 2 applies to any resource that meets the following criteria:

• It is not natively GFIPM-aware.
• It does require local user accounts for access.
• It cannot be modified at the source code level because of business/technical impracticalities.
• Its access policy may require that each federated user have a unique account, or it may allow multiple users to share a group account.
• It may or may not require intersession persistence for an account, and it may or may not have any personalization requirements.

In this integration technique, access to the resource is provided for federation members via a reverse proxy architecture in which the proxy maps each GFIPM user into a corresponding user account for the proxied resource. The mapping from GFIPM user to back-end resource account may be many-to-one (using local accounts at the resource as group accounts for GFIPM users) or one-to-one (using individual accounts). The proxy must authenticate the user to the proxied resource using the appropriate account.

If access to the resource is to be permitted via group accounts, a typical configuration would consist of relatively few local accounts on the resource (e.g., the number of group accounts in the application), with each account corresponding to an access class, group, or role that would be used by many federation users. In this configuration, since the resource knows only group accounts, it has no way to know which specific GFIPM user is accessing it at any given time. Therefore, to provide end-to-end auditing, it is necessary to combine the proxy's audit logs with the resource's audit logs. Two NIEF participants have successfully enabled federation resources using group accounts in this manner.

If access to the resource requires each GFIPM user to have a unique back-end account with the resource, it is necessary to provision individual user accounts for access. The most elegant approach to solving this problem is to allow user accounts to be provisioned via an account sign-up page on the back-end resource, and configure the proxy to populate the resource's account provisioning (sign-up) page with GFIPM user attribute data extracted from a SAML assertion. If this type of dynamic account provisioning is not possible (for either business or technical reasons), the proxy can act as an account-linking bridge between GFIPM federated user accounts and local back-end accounts that have been pre-provisioned out-of-band.

In either scenario, the proxy must somehow know how to map each GFIPM user ID to a back-end user ID on the resource. This may be accomplished in several ways, but the most straightforward technique is for the proxy to maintain a database or map from one domain to the other. In some cases where accounts follow a regular form, a set of rules or algorithmic mapping may be possible.

Technique 3: Native GFIPM Enablement

If it is possible and practical to modify the source code of a resource during the federation enablement process, the resource can be configured so it natively understands GFIPM metadata and can exist in the GFIPM environment without the aid of a proxy.

If the resource is a newly developed application, it may be advantageous to design and build the application such that it fundamentally understands GFIPM Metadata as its primary internal model for fulfilling its requirements related to identifying the user, enforcing access control rules, and auditing access.

However, if the application already exists, it may be necessary to take an alternate approach and develop a GFIPM-aware module that exists within the application and serves to translate information from GFIPM metadata into the native user model that the application uses.

Issues related to account provisioning (dynamic or out-of-band) are the same for this technique as they are in the discussion above for Technique 2.

Go back