...

...

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 a normal common for startup-phase organizations, it becomes immensely problematic during growth. Core symptoms of poor IAM include:Confusing and onboarding

• Confusion and frustration with on-boarding of staff and members. (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.)
• Inability to fully disable accounts

...

• . (E.g. Charlie ended membership last year but still has an active login.)

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. No approvals required, but requires email verification, ToS agreement, and CAPTCHA validationManual 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 domain, and HSPC ID namespace. An active HSPC ID is required for:

• Membership self-management on the website.
• Access to digital downloads requiring registration RBAC.
• Logging into the freely available public FHIR sandboxSandbox system.
• Marketing email list opt-in/opt-out management. any materials
• Access to JIRA, Confluence and Atlassian tools.
• Usage of members-only tools and services such as the HSP Marketplace, Terminology Server and other . 

All HSPC members and staff . Usernames do MAY or MAY NOT be 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. For this reason, a blacklist will of externally-used names SHOULD be maintained. Subject . (E.g. "platform@hspconsortium.org", "roadmap@hspconsortium.org" etc)

Functional Requirements

SHOULD allow for two-factor authentication in the future.

Non-Functional Requirements

• MUST be a "buy/license" product, as opposed to "build".
• SHOULD be available as a F/OSS license
• Technology

In terms of software and infrastructure, HSPC ID is an instance of Gluu Server Open Source

Implications

e

Identity Provider

To avoid confusion and use correct semantics, the HSPC IDP "issuer" and URI/URL SHALL be: https://id.hspconsortium.org . This cannot be trivially changed, and SHOULD be treated as a permanent, immutable decision. OAuth "subject" identifiers similarly need to be treated as immutable.

...