Difference between revisions of "Federation API"
(→References) |
(→References) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 16: | Line 16: | ||
==Solution== | ==Solution== | ||
In order to satisfy [[User]]s in a heterogeneous environment each response needs be interpretable on its own irrespective of the federation or API version used. In the sample from the link below it can be seen that the version a federation office are the first mandatory items and that multiple results are possibly displayed (including no results at all). We expect that conversion to jwt is optional and might only occur when one specific endpoint is requested. | In order to satisfy [[User]]s in a heterogeneous environment each response needs be interpretable on its own irrespective of the federation or API version used. In the sample from the link below it can be seen that the version a federation office are the first mandatory items and that multiple results are possibly displayed (including no results at all). We expect that conversion to jwt is optional and might only occur when one specific endpoint is requested. | ||
| + | |||
| + | Example: | ||
| + | <pre> | ||
| + | { | ||
| + | "version": "OID FED 0.04", | ||
| + | "iss": "TrustRegistry.us", | ||
| + | "iat": "201811031839", | ||
| + | "frameworkOffice": "tid:idef", | ||
| + | "members": [ | ||
| + | { | ||
| + | "sub": "www.authen2cate.com", | ||
| + | "serviceName": "Authen2cate", | ||
| + | "serviceDesc": "Authen2cate is a full-service secured cloud based identity management solution that provides single sign-on (SSO), multi- factor authentication and identity management services for cloud, web, VPN and mobile resources.", | ||
| + | "providerName": "Authen2cate, LLC.", | ||
| + | "dateListed": "October 31 2017 2:47pm", | ||
| + | "services": [5 items], | ||
| + | "roles": [rp iap ua], | ||
| + | "counts": {3 items}, | ||
| + | "scores": {9 items} | ||
| + | } | ||
| + | ] | ||
| + | } | ||
| + | </pre> | ||
==References== | ==References== | ||
*Example of conversion from existing IDEF registry to a OpenID-like syntax. http://trustregistry.us-east-2.elasticbeanstalk.com/Registry/Display?QueryString=&reqtype=json | *Example of conversion from existing IDEF registry to a OpenID-like syntax. http://trustregistry.us-east-2.elasticbeanstalk.com/Registry/Display?QueryString=&reqtype=json | ||
| − | + | *[https://www.incommon.org/federation/ InCommon Federation] has been running for several years now with [[SAML 2.0]]. | |
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Standard]] | [[Category:Standard]] | ||
Revision as of 17:26, 4 November 2018
Full Title or Meme
A Federation API is designed to allow communicating parties to determine if the other party is a member of a particular federation and which options of the federation are supported.
Context
Each federation publishes a Framework Profile which describes the conditions for membership in the federation. THe term profile is used in the context because the base assumption is that trust federations are single rooted into a common trust framework in which all are bound by a set of baseline functional requirements (the BFR).
The existing SAML 2.0 Federation API is purely technical. It is designed to allow one Entity to get configuration data from another Entity where a single Framework Profile is assumed to apply to all entities. As Web Sites discover a need to belong to adhere to more than one Framework Profile because of a diverse set of Users, and the Users are sufficiently savvy to pick and choose from Framework Profiles based on their own needs, a more complex set of conditions need to be accommodated. In particular it is expected that Users will be able to query one or more Federation APIs to get a list of Web Sites that meet their queiry.
Problem
The Federation API need to solve the following set of User expectations.
- The user is not familiar with the specific syntax of any federation by wishes to learn more about the members by creating a query in their own language.
- Framework Profiles will each create a different list of required and optional elements.
- Each Federation Office will have their own update cycle with respect not only to their own elements but also the implemented version of the API.
- Users will likely be getting and saving API information from a variety of federations in a single search for relevant Web Sites.
Solution
In order to satisfy Users in a heterogeneous environment each response needs be interpretable on its own irrespective of the federation or API version used. In the sample from the link below it can be seen that the version a federation office are the first mandatory items and that multiple results are possibly displayed (including no results at all). We expect that conversion to jwt is optional and might only occur when one specific endpoint is requested.
Example:
{
"version": "OID FED 0.04",
"iss": "TrustRegistry.us",
"iat": "201811031839",
"frameworkOffice": "tid:idef",
"members": [
{
"sub": "www.authen2cate.com",
"serviceName": "Authen2cate",
"serviceDesc": "Authen2cate is a full-service secured cloud based identity management solution that provides single sign-on (SSO), multi- factor authentication and identity management services for cloud, web, VPN and mobile resources.",
"providerName": "Authen2cate, LLC.",
"dateListed": "October 31 2017 2:47pm",
"services": [5 items],
"roles": [rp iap ua],
"counts": {3 items},
"scores": {9 items}
}
]
}
References
- Example of conversion from existing IDEF registry to a OpenID-like syntax. http://trustregistry.us-east-2.elasticbeanstalk.com/Registry/Display?QueryString=&reqtype=json
- InCommon Federation has been running for several years now with SAML 2.0.
