Difference between revisions of "SecurityPrincipal FHIR Resource Proposal"
| Line 46: | Line 46: | ||
This resource represents: | This resource represents: | ||
| − | * a well understood, "important" concept in the business of healthcare - an authenticated. | + | * a well understood, "important" concept in the business of healthcare - an authenticated user. |
| − | ** note: this concept is not healthcare specific, which is why this resource and it's related resources are a subsystem that are not allowed to become | + | ** note: this concept is not healthcare specific, which is why this resource and it's related resources are a subsystem that are not allowed to become an API dependency |
* a concept (user/device) expected to be tracked with distinct, reliable, unique ids | * a concept (user/device) expected to be tracked with distinct, reliable, unique ids | ||
* a concept that is created, queried and maintained | * a concept that is created, queried and maintained | ||
* the initial proposal expects 10 elements | * the initial proposal expects 10 elements | ||
| − | * is well decoupled from other concepts | + | * is well decoupled from other concepts |
==Expected implementations== | ==Expected implementations== | ||
Revision as of 23:55, 27 July 2014
This page documents a Pending FHIR Resource Proposal
Contents
- 1 SecurityPrincipal
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
SecurityPrincipal
Owning committee name
FHIR Core Project
Contributing or Reviewing Work Groups
- Security
- IHE
FHIR Resource Development Project Insight ID
FHIR core project
Scope of coverage
Some implementations find that it would be useful to be able to manage user accounts and rights through the FHIR interface. This is true whether they use their own user identity system, or some external identity provider such as LDAP, Windows Domain, or Facebook/Google/etc,since even when using these external identity providers, there are still rights/roles things to say that are specific about FHIR. So we have decided that FHIR will provide a specific set of resources for this. Note that it will not be required for an implementation to use these resources in order to implement it's security system - they are defined for convenience should an implementation wish one.
See FHIR Security Management Subsystem for further information.
The SecurityPrincipal resource allows a system to describe either human user or a device/software application that is authorised to use the FHIR API, and manage both how it is authenticated, and what authorisations it has.
- subject: either device or person (or perhaps organisation)
- usage: manage authentication and/or authorization
- this resource is not limited by discipline/context/locality
RIM scope
- A principle is an entity (Person/Organisation/Device) playing the role of Licensed Entity (LIC)
Resource appropriateness
This resource represents:
- a well understood, "important" concept in the business of healthcare - an authenticated user.
- note: this concept is not healthcare specific, which is why this resource and it's related resources are a subsystem that are not allowed to become an API dependency
- a concept (user/device) expected to be tracked with distinct, reliable, unique ids
- a concept that is created, queried and maintained
- the initial proposal expects 10 elements
- is well decoupled from other concepts
Expected implementations
- the FHIR reference server will implement this
- several other connectathon attendees have asked for this functionality
Content sources
- IHA XUA
- OpenID Connect
- Microsoft Documentation - WCF Security & LDAP documentation
Example Scenarios
- define user/software that is allowed to use a server
- define claims for rights that apply to an identified user or software application
Resource Relationships
- this resource refers to other resources that identify the same principal (patient, practitioner, organization, device)
- this resource refers to a security rights group for grouping claims of rights
- there is also a SecurityRole group for defining additional roles a user may claim
Timelines
Fro development for QA/DSTU2
gForge Users
Core team
