IMS Global TECH TALK
Contributed by Dr. Colin Smythe, IMS Chief Architect
The IMS Security Framework 1.1: Security for All IMS Service-Based Specifications
Providing secure access between edtech systems and learning resources is essential. We've published many service-based specifications for edtech interoperability, including Learning Tools Interoperability/LTI Advantage, OneRoster, and Comprehensive Learner Record. Addressing secure data exchange, authentication, and authorization are important parts of our specifications. These needs are not unique to edtech, but some of the most vulnerable users in society make extensive use of edtech systems and resources.
In May 2019, IMS published the Security Framework 1.0. This framework established the set of security patterns and techniques approved for use in an IMS interoperability specification. Experience has shown that security requirements change continually, and a solution that works today may become vulnerable tomorrow. In August 2021, IMS published the Security Framework 1.1, which included new security features and some refinements reflecting the two years of experience gained from using the original version. The Security Framework places IMS in a very strong position with respect to best practice adoption and adaptation. Nevertheless, we already know that it will need a further revision in the next 18-24 months.
The IMS staff are not experts in security but IMS member organizations, presently over 675, have experts in just about every area of technology. So, we have been able to bring their expertise together to create the IMS Security Framework.
Security concerns cover all market sectors. Several other standards organizations have created solutions that have very broad adoption. The approach by IMS when creating the Security Framework is to adopt this best practice and adapt it to meet the specific needs of edtech interoperability. We achieve secure communication by requiring the use of Transport Layer Security (TLS) as defined by the Internet Engineering Task Force (IETF) Request For Comment (RFC) 8446. Providing authentication and authorization is more complicated. Authentication is the confirmation that a user is who they claim to be while authorization gives those users permission to access a resource. In the IMS specifications, there are three scenarios for which awe must support authentication and authorization:
Web services-based information exchanged between systems where there is an established trust relationship (OneRoster is a typical example)
Web services-based information exchange between systems where there is no established trust relationship (Comprehensive Learner Record is a typical example)
Moving users between edtech systems that may or may not have an established trust relationship (LTI Advantage is a typical example)
Therefore, two third-party specifications have been adopted:
- OAuth 2 defined in IETF RFCs 6749 and 6750
- OpenID Connect from the OpenID Foundation and which is built upon OAuth 2 to provide authentication
One of the problems when combining specifications from several sources is to create a consistent terminology. In the Security Framework we have used the established IMS terminology as our basis and have been careful to explain how this is mapped to the terminology used in the third-party specifications.
In version 1.1 several functional additions have been made due to the requirements from new IMS specifications. These additions are:
- Support for access token refresh as part of the OAuth 2 Authorisation Code Grant workflow
- Support for access token revocation (using [RFC7009] as part of the OAuth 2 Client Credentials
- Support for access token and/or refresh token revocation (using [RFC7009] as part of the OAuth 2 Authorisation Code Grant workflow
- Support for dynamic client registration to simplify the use of OAuth 2 using [RFC7591] and [RFC7592]
- Support for dynamic client registration to simplify the use of OpenID Connect [OPENID-DCR] and [OPENID-DIS] for systems based upon LTI
- Definition of the use of a service discovery endpoint and the Service Discovery Document (SDD), based upon OpenAPI (JSON) file format, for obtaining a description of a service provider's service capabilities
Apart from a few bug fixes and corrections the new functionality added in version 1.1 is backwards compatible with version 1.0. Therefore, migration from version 1.0 to 1.1 is expected to occur as part of the natural revision cycle on a per IMS specification basis.
IMS Security Committee
The IMS Security Committee has been given the responsibility for maintaining the Security Framework. This committee brings together some of the IMS technical staff with experts in the field of security and edtech systems from the IMS Contributing Members. This committee provides IMS with awareness for state-of-the-art security best practices and insight into how organizations should apply these practices. The Security Committee also has responsibility for undertaking an annual security audit. This is a formal review of how the Security Framework is being applied in the IMS specifications as well as reviewing the effectiveness of the Security Committee itself. The audit report contains a set of short, medium, and long-term recommendations, which should be completed in the twelve months following the publication of the report.
The IMS architects are responsible for ensuring that the various specification working groups use the Security Framework appropriately. Before submitting a specification to the IMS Technical Advisory Board (TAB) for a vote on Final Release, the specification must be submitted to the Security Committee for formal review. If there is anything that may be contentious, then it is recommended that the specification is sent to the Security Committee for formal review as part of the creation of the Candidate Final Release process.
What would constitute being contentious? The use of the patterns defined in the Security Framework are not mandatory, but if other approaches are to be used, clear justification must be made: this includes when there is a decision not to include the use of security in the specification. In some cases, the security requirements for a specification may not be covered by the Security Framework. Therefore, an update of the Security Framework would be undertaken to include the new capabilities required by that specification. These new patterns would then become available for other IMS specifications. The annual security audit provides the final mechanism for evaluating the ways in which every IMS specification makes use of the latest version of the Security Framework.