Hi All,
This mail is regarding the project InCommon Federation compliance for WSO2 Identity Server. In the 1st phase, Metadata management and refreshment processes were done with the use of metadata aggregates. Details on the 1st phase can be found in [1]. During the 2nd phase, I focussed on new metadata service, Discovery Service and overall flow of the InCommon federation. >From the middle of 2019, InCommon has moved to a new metadata service name Per-Entity Metadata Distribution service (PEMD service) which is based on a Metadata query server (MDQ server). With the expansion of aggregates, the metadata consumers had experienced slow start-up times and high memory usage. Apart from that most of the consumers do not need metadata of all the entities, they use only a fraction of entities. It has consumed lots of memory for them to store unwanted metadata with the aggregates. Further a single error in the entity descriptor can cause an outage of the service. So they have implemented Per-Entity Metadata service. Per-entity metadata distribution service can retrieve metadata relevant to a specific entity from a metadata query service. Metadata related to an entity is stored in a specific URL, which can be uniquely identified by the entity ID in the entity descriptor tag. Also, it can be used to prefetch metadata related to an entity and cache it at the start-up and refresh it on a regular basis. For communication with the MDQ service, we need to use the metadata query protocol. The metadata query protocol is a REST-like API for requesting and receiving arbitrary metadata. The specification related to MDQ service is broken into two parts. 1. Base specification <https://datatracker.ietf.org/doc/draft-young-md-query/> [1] 2. SAML profile of the base specification <https://datatracker.ietf.org/doc/draft-young-md-query-saml/> that focuses on SAML metadata. [2] Benefits of per-entity metadata distribution service using the MDQ protocol. - Reduced memory and resource consumption by a metadata consumer since it need only request and consume metadata for entities with which it needs to federate. - Reduced load on the metadata distribution service since consumers only query for and download the actual entity descriptors they need. - Decoupling of entity descriptors so that errors for any single entity need not impede the distribution and consumption of the metadata for all other entities. - It helps to reduce network traffic, and resolve the brittleness of large aggregates. Risks associated with PEMD service - Unavailability of the metadata query service. - Poor responsiveness - Network failures - High latency Overcome risks associated with the PEMD service Above mentioned risks can be mitigated by implementing few capabilities in the sides of metadata clients (WSO2 IS). - A persistent caching mechanism that retains previously-retrieved metadata across software restarts so that it may be re-used if the software is restarted when the MDQ service is not available. A likely mechanism is caching to local disk and then consumption from the cache on restart. - A mechanism for pre-loading metadata for high-value IdPs and SPs and keeping it available. This enables successful operation the first time a high-value entity’s metadata is needed, even if the MDQ service is not available. - The ability to detect a failed query, retry appropriately, and after repeated completed but failed queries failover to a secondary MDQ service. A complete implementation would include the ability to mark an MDQ service as unavailable for some time but later test again and return to using it when the service is again available and completing successfully. - Likewise the ability to detect unresponsively (hanging) MDQ services or MDQ services that do not answer queries fast enough and similarly retry, mark as unavailable, and then later test for restoring into service such MDQ services. - Clients without the above capabilities can still use the per-entity metadata distribution infrastructure and interoperate with MDQ services but they risk lower availability for their users. To increase the metadata service availability Incommon uses two metadata distribution servers, primary and secondary. For the sites that are extremely critical or that do not have proper internet connectivity can implement a local metadata cache. Discovery Service In a federation, SP should know the user’s IdP where the user can be authenticated. So a Discovery Service provides a browser-based interface where a user can select his or her home organization. Discovery Service response with the entityID of the user’s IdP. A service provider uses this information to initiate SAML Web Browser SSO. InCommon Discovery service is implemented adhering to the OASIS Identity Provider Discovery Service Protocol and Profile <https://www.oasis-open.org/committees/download.php/28049/sstc-saml-idp-discovery-cs-01.pdf> [4]. When registering SP metadata it is a must to include the correct endpoint of the service provider as the attribute value of Location in the <idpdisc: DiscoveryResponse>to send the discovery service response. So the discovery service compares the return URL in the request with the above attribute value. If both are the same, the response will be sent to the correct endpoint. Below are the flows that we identified to incorporate PEMD service There we identified two flows related to the InCommon Federation. 1. WSO2 Identity Server as a Service Provider 2. WSO2 Identity Server as an Identity Provider WSO2 Identity Server as a service provider. When a user tries to access an application registered in WSO2 IS, it acts as a service provider. It should, 1. Search for a prevailing session of the user 2. Request Discovery service for user’s IdP 3. Request metadata of the IdP from MDQ service 4. Request authentication from the user’s IdP. Flow related to WSO2 IS as an SP in InCommon Federation. WSO2 Identity Server as an Identity Provider. When WSO2 IS gets a request from a service provider in InCommon Federation to authenticate a user registered in WSO2 IS, WSO2 IS acts as an IdP. It should, 1. Request SP’s metadata from MDQ service 2. Authenticate the user 3. Respond with the requested attributes. Flow related to WSO2 IS as an IdP in InCommon Federation. Within my project scope, I researched metadata service and Discovery Service of the InCommon Federation. Apart from that, there exists another 3 services, Error handling services, Gateway services, Authn and Authz Services <https://spaces.at.internet2.edu/display/InCFederation/Authn+and+Authz+Services> in InCommon Federation. There is a verification spec named SAML V2.0 Deployment Profile for Federation Interoperability [5] to verify if the saml implementation is interoperable with InCommon saml requirements [1] https://datatracker.ietf.org/doc/draft-young-md-query/ [2] https://datatracker.ietf.org/doc/draft-young-md-query-saml/ [3] https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html [4] https://www.oasis-open.org/committees/download.php/28049/sstc-saml-idp-discovery-cs-01.pdf [5]. [IAM] InCommon Federation compliance for WSO2 Identity Server Kind regards, Sithara Nishadini -- *Sithara Nishadini*| Intern | WSO2 Inc. (m) 0719801636 |(e) [email protected] [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
