Review assumptions at 16th General Meeting.

Problem

HSPC user accounts have not historically been centrally managed, with individual services maintaining their own user database for which it was authoritative. While this is common for startup-phase organizations, it becomes immensely problematic during growth. Core symptoms of poor IAM include:

• Confusion and frustration with on-boarding of members and staff. (E.g. "Oh, to access service X, email Alice. For Y, email Bob.") 
• Inconsistent access permissions for members of equivalent role. (E.g. Alice and Bob have different access permissions despite sharing the same job.)
• Lack of off-boarding process. (E.g. Charlie ended membership last year but still has an active login.)
• Inability to define a clear information security posture. (Services/Resource all use disjoint policies and access processes) 

Additionally, sharing of resources inter-organizationally is not always achievable with manager-managed authorization. That is, HSPC MAY want to allow individual members to define who can/cannot access a service or resource directly, without going through formalized governance procedures with HSPC leadership for each resource instance. This is particularly important in health care scenarios involving patients' ability to define the 3rd parties users and systems able to access resources "owned" by said user.

Objectives

For HSPC to mature and grow, a centralized IAM system became necessary to:

• Establish an single sign-on (SSO) authority upon which all “Platform” systems, tools, and services may authenticate and authorize users.
• Allow HSPC staff to centrally manage member and non-member access to digital content in services in a role-based, manner.
• Provide a standards-based identity provider (IDP) for partners and cloud services to support HSPC member logins into 3rd-party systems.
• Enable integrated account self-service for administrative membership functions.
• Flexibly account for wide-ranging unknown future usage scenarios.

Solution

Business Qualities & Requirements

HSPC IDs SHALL be free and open for individuals to self-register, regardless of current or intended membership status. Manual approval of IDs by HSPC management SHALL NOT be required; however, email addresses MUST be verified prior to ID activation, as is acceptance of the HSPC Terms of Service agreement. A CAPTCHA SHOULD be used, as well. Usernames MUST be unique within the HSPC ID namespace. An active HSPC ID is required for:

1. Membership self-management on the website.
2. Access to digital downloads requiring RBAC.
3. Logging into the freely available public FHIR Sandbox system.
4. Marketing email list opt-in/opt-out management.
5. Access to JIRA, Confluence and Atlassian tools.
6. Usage of members-only tools and services such as the HSP Marketplace, Terminology Server and others.
7. Restricted access to the HSPC Amazon Web Services (AWS) account.

All HSPC members and staff MUST have an HSPC ID to use any service requiring authentication. To allow for the plausibility of usernames being used for email purposes in be future, a blacklist of externally-used names SHOULD be maintained (e.g. "platform@hspconsortium.org", "roadmap@hspconsortium.org" etc). Long-term, this implies that future SaaS and on-premise services implemented by HSPC SHOULD strongly favor solutions capable of operating as an OpenID Connect resource server and/or client (preferred), or as a non-preferred alternative, SAML relying party (also supported by this solution).

To avoid confusion and use correct semantics, the HSPC IDP issuer URL SHALL be: https://id.hspconsortium.org . URIs used for native application purposes (such as iOS, Android etc) SHALL use namespace prefix of "hspc://" where applicable. These cannot be trivially changed, and SHOULD be treated as a permanent, immutable decisions. OAuth "subject" identifiers similarly need to be treated as immutable.

Identity Creation Requirements

During registration, users:

• MUST provide a first name, last name, email, and username. 
• MUST complete an email verification step.
• MUST NOT choose a blacklisted username to avoid potential conflicts with local system accounts and reserved words.
• SHOULD provide additional contact information.
• SHOULD use an email registered with a Gravatar profile.

Functional Requirements

The HSPC ID System:

1. SHALL provide a web-based ID registration form for guests and members.
2. SHALL provide a web-based management GUI for staff.
3. SHALL serve as an OpenID Connect Provider (OP), and thus MUST implement all core OAuth 2.0 flows.
4. SHOULD support OpenID Connect Logout Tokens.
5. SHALL support the configuration of custom scopes.
6. SHALL support OAuth 2.0 HEART extensions for User-Managed Access (UMA).
7. SHOULD support core SAML authentication/authorization flows.
8. SHOULD allow for two-factor authentication in the future that SHALL NOT be enabled at deployment time.

Non-Functional Requirements

The HSPC ID System:

• MUST be a "buy/license" product, as opposed to "build".

• SHOULD be available under a F/OSS license.

• MUST have a sensible deployment process and maintenance update cycle.

• MUST include sufficient technical documentation and existent community of users. 

• SHOULD provide an option for paid support that HSPC MAY or MAY NOT elect to purchase in the future. 

Technology

In terms of software and infrastructure, the HSPC ID System is an instance of Gluu Server Community Edition v3: one of the leading fully Open Source implementations of OIDC, SAML, UMA and other standards in a single software product, easier to configure than MITREid and friendlier to the Open Source-only deployment than OpenAM/OpenSSO. It is largely written in Java and released under the MIT license. Pre-packaged binaries are provided for both Ubuntu and CentOS Linux distributions. Gluu Server is deployed to the Platform Engineering Virtual Private Cloud on AWS and Internet accessible at https://id.hspconsortium.org. To avoid inadvertent circle dependencies, Gluu Server is run on a dedicated Ubuntu Server VM. The following standards are enabled in HSPC's deploy implementation:

• OAuth 2.0
• OpenID Connect
• SAML 2.0
• UMA (User-Managed Access OAuth 2 profile)
• SCIM - important for future ActiveDirectory synchronization
• Passport.js - Not a standard, but provides "inbound SAML"-like social login support to supersede the need for a custom social identity management application

This combination supports current usage scenarios, likely future ones, and social login without requiring HSPC, and the platform work group specifically, to maintain custom software products. The current major release of Gluu Server is backend by a normal OpenLDAP directory than can, if necessary, be queried out-of-band from the Gluu Server application. SCIM support further "designs in" the possibility of user/group synchronization across organizational boundaries and some API compatibility with ActiveDirectory to support more complex business relationships between HSPC and partners. 

Gluu Server is very well documented. A vendor-managed support portal is available for anyone to access, though priority support requires a commercial support contract. Source code is developed publicly on the GluuFederation GitHub account, which issue submission and tracking is also available.

Role-Based Service Access

Services and applications requiring a specific level of membership will need to request the appropriate scope(s) during the login flow as appropriate for that specific service/application. The System will be authoritative for maintaining role memberships and applicable authorization scopes as relevant to authentication and authorization flows.

Rough Project Tasks

1. Establish Gluu Server
   1. Set up in Platform VPC
   2. test heavily Either set up a new common IDP or use one of the existing instances.
2. Migration of existing services
   1. Migrate Logica Sandbox to the new IDP.
      1. Need help from Travis with this one  ... Hopefully some combination of adding the IDP configuration and migrating existing user accounts.
   2. Enable AWS to support SSO login.
      1. Update AWS IAM group policies
      2. SAML probably
      3. Remove unneeded users
      4. Account for lock-out situations (since Gluu is hosted on AWS)
   3. Reconfigure the WEBSITE to use the IDP in additional to local authentication.
      1. Evaluate and install membership management plugin(s), such as MemberPress.
      2. Add IDP configuration
      3. Possibly relocate hosting situation
      4. Add MSP support and configure applicable hooks to IDP 
   4. Migrate Marketplace to the new IDP
      1. Probably disable the Google and Microsoft login options.
      2. Re-authorize existing accounts
   5. TermSpace? Need to ask Susan Matney and Peter Haug about this.
3. Configuration of new services
   1. Terminology servers to support authenticated and authorized access.
      1. Ontoserver - not sure if this is possible
      2. HAPI-FHIR
   2. Developer instructions for future authoring tools
4. Maintenance and updates
   1. Establish maintenance and availability policies
   2. Document all this stuff