InCommon BasicsInCommon serves the U.S. education and research communities, supporting a common framework for trustworthy shared management of access to on-line resources. Through InCommon, Identity Providers can give their users single sign-on convenience and privacy protection, while online Service Providers control access to their protected resources. A federation, through its trust agreements and federating software, allows identity providers to manage user privacy and information exchange. Service providers no longer need to provision identity accounts, instead leveraging the identity provider’s identity system. InCommon enables production-level end-user access to a wide variety of protected resources using standards-based, SAML-compliant single sign-on and federating software, such as Shibboleth®. How InCommon WorksSee a larger version of the graphic. InCommon's value is based on federated identity management. A user clicks on a Service Provider’s resource. Using federating single sign-on software, the user is authenticated by his or her Identity Provider, which releases only enough identity data to allow the Service Provider to make an access decision. The Service Provider uses the minimum identity information necessary to control access to the resource. InCommon participants could spend time establishing operating principles, technology hooks, and agreed-upon data exchange elements with each partner; or they could do it once through InCommon and then leverage these common elements for many relationships. Additional background information is available about Shibboleth federating software, other federations, and about middleware in general. Need Help?
|
InCommon Case StudiesInCommon case studies provide information about current InCommon Participants and how they are implementing innovative approaches to federating identity and access management systems. See our complete list of case studies. Return on InvestmentThe Swedish virtual organization SWAMI (Swedish Alliance for Middleware Infrastructure) has demonstrated how federated identity management can lower the costs of identity proofing [pdf]. In addition to the write-up, SWAMI has provided a spreadsheet used to determine the per-student cost [xls]of identity proofing. Ready the PipesA Campus Technology report on why now is the time to get your identity management infrastructure in place - and federating is a key part of that strategy. Ready Your PipesSeveral companies provide either consulting or turn-key solutions for either identity management or federated IdM, or both. InCommon Affiliates support the federation and have expertise and solutions that you may find valuable. DefinitionsIdentity Provider (IdP): An identity management system, providing user IDs and passwords and storing the accompanying data. Service Provider (SP): The operator of a protected online service. Also referred to as resource providers. Attribute: A single piece of information associated with an identity database record. Examples of an attribute are name, phone number and group affiliation. Federations define a common set of attributes so members can speak a common language. Assertion: Identity information provided by an Identity Provider to a Service Provider. The assertion carries with it the attributes required by the Service Provider for access. The IdP authenticates a user, then asserts the attributes the Service Provider will use for authorization. Trust Fabric: The use of common standards for interaction and for identity proofing (ensuring that those who receive user IDs are who they say they are). Metadata: Data about data. Metadata is an XML file that describes index-type information for an entire data set. Metadata describes the context, content and structure of records. |

Do limits on time, resources, or expertise have you stymied? Several companies provide either consulting or turn-key solutions for either identity management or federated IdM, or both.