Hi All,

This mail is regarding the project InCommon Federation compliance for WSO2
Identity Server. The main objective of the 1st phase of this project was to
gather requirements of InCommon Federation which are needed to comply with
their participating Service Provider and Identity Provider applications.
With that, we were able to identify the gaps in WSO2 IS to support the
InCommon Federation and the approaches to cater to the gaps identified.

Refer [1],[2],[3] for more details.

During federation, entities should be identified by each other for
communication. So they need to exchange their metadata in a trusted manner.
Each organization should submit metadata of the SPs’ and IdPs’ to the
InCommon during the registration process uniquely. The metadata submitted
by organizations is aggregated into aggregates where the entities can
download it through permanent HTTP locations.



Metadata refreshment is updating the already configured data about SPs and
IdPs in the WSO2 Identity Server. InCommon specifically mentions the
following flow of activities for the metadata refreshment




   1.

   Choose one of three metadata aggregates (Preview, Main, & Fallback)
   2.

   Obtain an authentic copy of the Metadata Signing Certificate
   3.

   Using the Metadata Client Software (WSO2 IS)
   1.

      Refresh metadata at least daily (but more often if possible, minimum
      hourly)
      2.

      Validate the expiration date on downloaded metadata
      3.

      Verify the XML signature on downloaded metadata
      4.

   Adjust outbound firewall rules (if necessary)


There were different requirements identified and WSO2 Identity Server needs
to do some modifications to support InCommon federation.

InCommon Federation requirements can be mainly categorized into three parts.

   1.

   Compatibility of SAML V2.0
   2.

   Federation Metadata Refreshment
   3.

   Support eduPerson Attributes

SAML V2.0 compatibility

   1.

   Regarding the SAML v2.0 requirements, the following metadata elements
   are not included in WSO2 IS
   1.

      Scope in IdP metadata
      2.

      User Interface Information
      3.

      Contact information
      2.

   There is an error-handling URL already in the IS, but it doesn’t resolve
   the required purpose of InCommon Federation.
   3.

   There are not <extension> element used in metadata but InCommon
   Federation metadata contains <extension> elements for “RegistrationInfo”,
   and “Organization” tags

Federation Metadata Refreshment

   1.

   No any method to automatically refresh metadata in WSO2 IS
   2.

   There is an option for SP file configuration in IS, but it also requires
   to have one file for one SP
   3.

   No way to any file configuration for IdP
   4.

   No HTTP Conditional GET supports to use in the hourly refreshment of
   metadata in IS
   5.

   No option to search configured SPs and IdP in IS management console
   6.

   No technical implementation to read a large XML file and configure SPs
   and IdPs

Support eduPerson Attributes

   1.

   No eduPerson claim dialect is available in IS
   2. No attribute such as FriendlyName to include in the SAML response.


Approaches to Cater to the Gaps

   1.

   As eduPerson attributes are not included in any existing claim dialect,
   a new claim dialect should be implemented. Using that, claims in WSO2 local
   dialect can be mapped into relevant eduPerson claims.
   2.

   Use the description section to map FriendlyName of the attribute since
   it requires in the SAML response. This may be changed if there is a better
   way
   3.

   Create independent CLI tool to handle the entire metadata refreshment
   process
   4.

   That will synchronously configure SPs and IdPs into the server. There
   will not be any overheads in IS, other tasks are also safe to proceed
   5.

   Allow HTTP Conditional GET support in tool. Thus, the hourly refreshment
   process of metadata can be done
   6.

   Add new feature to IS for searching already configured SPs and IdPs
   7.

   The tool will be able to read the desired metadata aggregate and give
   those SPs and IdPs metadata to relevant APIs to configure in IS
   8.

   When the configuration is happening, the system will display the current
   process of the configuration either configuring, success, or failed
   9.

   There will be another feature to track failed SPs and IdPs in the
   configuration process.


The architecture Diagram for the Metadata management and refreshment
process in WSO2 IS.


[1]. [Dev] [IS] InCommon Federation Compliance for WSO2IS - UI Component

[2]. [IAM] Configure Requested Claims based on the Service Provider Claim
Dialect

[3]. [Dev][IAM] InCommon Federation Compliance for WSO2IS - eduPerson Claim
Dialect

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

Reply via email to