1 of 28

Step-by-Step Guide to Offering Services in the InCommon Community

1

2 of 28

Prerequisites for This Learning Module

The material covered in the “Get Started” section of the InCommon Federation Library [2]
General knowledge of federated identity and access management
General knowledge of the provision of cloud computing services

2

3 of 28

10,000 Foot Overview

Determine Your Role(s) in Providing the Service.
Prepare for Integration into the Federation

What you need to do depends on your role. (You may be filling one or more of these roles.)

Register Your Service’s Federation Metadata

See Get Started after Joining the InCommon Federation [1] for more information.

We focus on determining your role and preparing for integration in this learning module.

Service Operators establish the policies that govern the service offering, who is authorized to use it, etc.
Platform Deployers deploy and operate the software
Software Implementers create the software used to implement the service

3

4 of 28

Determine How Your Offering Contributes to Providing the Service

4

5 of 28

Online Services Have Three Layers

Software determines the potential functionality of the service.
Platform is a deployment of the software that supports the Service.
Service is what is actually delivered to its users; it includes the Software and the Platform, as well as all other functions that may be required, such as user administration, user support, marketing, policy and legal compliance, etc.

5

Service

Platform

Software

6 of 28

Which Layer You Support Determines Your Role

Service Operator - The role that is responsible for the Service. The Service Operator establishes the service’s policies, manages its business, and oversees its technical operation (which may be outsourced to a SaaS Platform Deployer).
Platform Deployer - The role that is responsible for the Platform used to provide the Service Operator’s Service.
Software Implementer - The role that implements the Software used by the SaaS Platform Deployer.

6

Service

Platform

Software

7 of 28

Example: Enterprise Video Conferencing

State U provides a video conferencing service, based on Whiz.com, for its staff and faculty, as well as others who collaborate with them. Whiz.com operates the technology, and State U determines who is allowed to use the service, establishes

7

Service Operator	State U
Platform Deployer	Whiz.com
Software Implementer	Whiz.com

8 of 28

Example: Resources for (Any) College Student

Students-R-Us operates a service for college students at all universities, providing information about scholarship opportunities, where to find cheap textbooks, ratings of university student services, etc. It is hosted by WebHost Inc., and WebHost deploys software created by the Drupal Foundation open source project.

8

Service Operator	Students-R-Us
Platform Deployer	WebHost Inc.
Software Implementer	Drupal Foundation

9 of 28

Example: Simulation of the Geographic Spread of Infectious Disease

The Institute of Disease Dispersal provides a simulation model to help regional health officials to understand the spread of epidemics within their regions. IDD researchers developed the simulator's software, which is operated by their graduate students.

9

Service Operator	Institute of Disease Dispersal
Platform Deployer	Institute of Disease Dispersal
Software Implementer	Institute of Disease Dispersal

10 of 28

Prepare for Integration:

Service Operators

10

11 of 28

Your Organization’s Responsibilities

Understand collaboration in the R&E community
Register your service provider
Community Expectations

What the community expects of you, and what you can expect of the community
(Community standards)

Understanding collaboration and federation in research and education [14]
Metadata Service [8]
Introduction to Federation Manager [15]

11

12 of 28

Community Expectations

As the operator of a Service Provider, you must not misuse the identity information you receive, and you must protect its privacy
You can expect operators of Identity Providers to provide accurate and timely identity information, when that release is allowed by their policies.
All participating institutions are expected to adhere to best practices for the organizational, operational, and technical issues related to the accuracy, availability, and security of their services

If you haven’t already taken Module 2 - InCommon Federation as Standards and Practices, it provides more details.
The following documents provide more information:

InCommon Participation Agreement [3]
Trusted Relationships for Access Management: The InCommon Model [12]
Baseline Expectations [4] - the process by which community expectations evolve over time.

12

13 of 28

Service Operators: Adhere to Community Standards

Adhere to the terms of the InCommon Participation Agreement [3], including the InCommon community's Baseline Expectations [4], as they evolve to address the changing IAM ecosystem over time. Ensure that your Software Implementer and SaaS Platform Deployer partners enable you to do this.

See the “Get Started” section of the InCommon Federation Library [2] for details.

13

14 of 28

Service Operators: Understand the Community

Understand your R&E clients.
Understand multilateral federation.

Identity data is sourced from multiple authoritative systems, including student systems, human resources, among others.
Seasonal student and staff turnover requires markedly different processes for user creation and service provisioning and de-provisioning.
Universities play by different policy and compliance rules than private industry.
Inter-institutional collaboration is common in higher education. The users of your service may not be drawn from a single institution.
See Things to Consider When Joining the InCommon Federation [13] for what is expected of you and what you can expect of others.

14

15 of 28

Prepare for Integration:

SaaS Platform Deployers

15

16 of 28

Platform Deployers: Technical Standards

Be conformant with the SAML V2.0 Deployment Profile for Federation Interoperability.
Make use of the SAML V2.0 Subject Identifier Attributes Profile.

Also accommodate the use of legacy identifier attributes, such as eduPersonPrincipleName (ePPN) and eduPersonTargetedID (ePTID).

Configure your platform to utilize the Metadata Query Protocol (MDQ) to access federation metadata.

SAML V2.0 Deployment Profile for Federation Interoperability [5]
SAML V2.0 Subject Identifier Attributes Profile V1.0 [6]
SAML V2.0 Implementation Profile for Federation Interoperability [7]
InCommon Metadata Service [8]
Navigating Federated Identifiers section of this presentation

16

17 of 28

Platform Deployers: Support Your Service Operators

Allow Service Operators to include multiple identity providers, even those used by other service instances.
Support a rich set of identity attributes
Provide tools and documentation to facilitate your Service Operators' responsibilities to deliver services that are fully integrated into the federation.

The eduPerson [9] schema provides a list of useful attributes (e.g., email or a friendly name).

The availability of these attributes is subject to (potentially differing) policies of the identity providers. If an identity provider will not provide you with something that you need, consider requesting it directly from the user.

17

18 of 28

Prepare for Integration:

Software Implementers

18

19 of 28

Prepare for Integration - Software Implementers

Recognize that your software does not have complete control of user experience.

Friendly user names vs. federated identifiers
URL for error handling

While federated identifiers look like electronic mail addresses, they are not. If you need an electronic mail address for the current user, provide the ability to request it as a separate attribute.

Federated identifiers are often long and "ugly.” If you need a friendly name for interacting with the current user, provide the ability to request the user's name as a separate attribute from the identifier.
Make use of the error URL advertised in federation metadata by the identity provider, for example when you do you do not receive required attributes.
See How to Start Offering Services and the Cloud Services Cookbook.

19

20 of 28

Home-Grown SAML Software Considered Harmful

There are many nuanced aspects of federation and the SAML protocol suite that, if not addressed properly, can result in user frustration, significant security failings, and operational inefficiencies. We recommend off-the-shelf SAML software, rather than writing your own., but if you must build home-grown SAML software:
Take a close look at Shibboleth, OpenSAML, SimpleSAMLphp, and other widely deployed and well supported software before embarking on a home-grown SAML implementation.

If you must...

Make your software capable of conforming with the “Common Requirements” and “Service Provider Requirements” sections of the SAML V2.0 Implementation Profile for Federation Interoperability [7]
Provide documentation describing how a SaaS Platform Deployer can configure and deploy your software to conform with the SAML V2.0 Deployment Profile for Federation Interoperability [5]

20

21 of 28

Navigating Federated Identifiers

21

22 of 28

Navigating Federated Identifiers - What to Request

First, if you do not need a unique identifier, do not request one. This enhances privacy, and you can still make authorization decisions based on entitlement and affiliation attributes without knowing the user's unique identity.
If you do need a unique identifier, but that identifier need not be shared with other services (or policy and/or law prevent such sharing), request the OASIS Pairwise Subject Identifier [6]. This enhances privacy protection and also shields you from potential security threats arising from breaches of other services that would otherwise share the same identifier.
If you need a unique identifier, and that identifier must be shared with other services (and policy and/or law permit such sharing), request the OASIS General Purpose Subject Identifier [6]. Acceptance of the risk to privacy protection and security is often warranted to support research collaborations involving participants and services from multiple institutions.

22

23 of 28

Navigating Federated Identifiers - Fallback Options

If you find that the selected identity provider cannot provide your preferred identifier, what happens next will depend on the nature of your service. Potential, and perhaps less desirable, options are:

If the General Purpose Subject Identifier [6] is not available, potential substitutes are eduPersonUniqueId [9] and eduPersonPrincipleName [9].
If the Pairwise Subject Identifier [6] is not available, eduPersonTargetedID [9] is a potential substitute.
Try another identity provider that may provide the identifier you require.

Failing all options, you may need to deny access to this user.

23

24 of 28

Navigating Federated Identifiers - More Information

Choosing the Right Federated User Identifier [10]
SAML V2.0 Subject Identifier Attributes Profile Version 1.0 [6]
See Understanding Federated User Identifiers for more information about the pros and cons of different identifiers.

24

25 of 28

Continue the exploration

25

If you have not already done so, continue to the other modules in this course to learn more about how components in the InCommon Federation work together to enable streamlined and trusted research collaboration.

InCommon Federation as Standards and Practices

Module 2

InCommon Federation as Infrastructure

Module 3

Providing Single Sign-On (Identity Services)

Module 4

Offering Resources and Application Services

Module 5

InCommon Federation as a Community

Module 6