FHIR Security Management Subsystem

Introduction

At the HL7 meeting in Phoenix May 2014, the security committee agreed to the addition of a light-weight user / provisioning framework for FHIR. The idea of this is to allow systems to expose some user and security management over the FHIR interface. The key proviso is that it must not be necessary to use these resources in order to use or provide a FHIR server.

Also note that this subsystem does not dictate any authentication or authorisation techniques - that will be done in a different piece of work

Functional Requirements

• to allow for creation of users on the interface
• to allow for the management of user privileges on (whether explicitly or implicitly created (e.g. but OAuth login)
• to manage client applications as well as human users

Design

Proposal for 3 resources

• SecurityPrincipal : a human or software device that uses the server
  • name [1..1]
  • description [0..1]
  • picture [0..1]
  • email [0..1]
  • phone [0..1]
  • login [0..1]
  • password hash [0..1]
  • ip mask [0..*]: v4 or v6
  • claim (0..*]
  • party [0..*] Resoruce(Any): identifies other resources that represent this party (patient, practitioner, organization, device)
    • type [1..1] URI: the type of claim
    • value [1..1 String: type depends on claim type but usually a URI
  • group [0..*] reference to SecurityGroup that assigns roles
  • + also define a related service: hash a password for a SecurityPrincipal resource

• SecurityGroup : allows for assigning roles to multiple groups
  • name [1..1]
  • description [0..1]
  • claim (0..*]
    • type [1..1] URI: the type of claim
    • value [1..1 String: type depends on claim type but usually a URI

Claims: you can use claim types from other specifications and in addition, FHIR defines 2 claim types:

• http://hl7.org/fhir/tag/security: a reference to a [security label])
• http://hl7.org/fhir/security-role: a reference to a security role defined by FHIR

The FHIR Specification will define the following security Roles:

• http://hl7.org/fhir/security-role/[grant|deny]/[x], where x =
  • the name an http operation
  • [name] where name is an operation defined not a type
• http://hl7.org/fhir/security-role/[type]/[grant|deny]/[x], where
  • type is a resource type (correct case)
  • [x] is the name an http type operation, or an operation defined on a type

In addition, implementations can define their own claim types using the resource

• SecurityClaimType : the definition of a security claim that may be made.
  • type [1..1] uri: the claim type for this claim
  • value [1..1] string: the value of the claim - usually a URI
  • name
  • description

Notes:

• these security roles are only defined for user on SecurityPrincipal & SecurityGroup, and are not used elsewhere (unlike security labels)

Original Skype Thread

Today we agreed to add a provision subsystem to the FHIR API. It will be an entirely optional section of the API that allows you to manage users, permissions, and basic service provisioning stuff.

[9/05/2014 4:57:19 PM] Grahame Grieve: this is something lots of implementers have asked for.

[9/05/2014 4:57:49 PM] Grahame Grieve: please either email me or make notes here if you would be interested in implementing this interface, and if so, what features and shape you'd like it to have

[9/05/2014 4:57:59 PM | Edited 4:58:07 PM] Josh Mandel: Whoa!

[9/05/2014 4:58:15 PM] Grahame Grieve: me: i'd like users, groups, roles.

[9/05/2014 4:58:49 PM] Grahame Grieve: it will be kept simple on the basis that anyone wanting sophistication will do it some other way

[9/05/2014 5:00:30 PM] Reuben Daniels: grahame: definitely in favour of users, groups, roles. you not that keen on permissions/authorisation/etc ?

[9/05/2014 5:01:32 PM | Edited 5:03:20 PM] Grahame Grieve: roles = permissions, I think. auth - of course you have to have that. not sure what you mean

[9/05/2014 5:05:55 PM] Reuben Daniels: Hmm, I would have thought Permissions and Roles are separate things. you assign one or more permissions to a role, and then assign one or more roles to a user. that said, not sure if there's anything else you would add to a Role

[9/05/2014 5:06:11 PM | Edited 5:06:21 PM] Josh Mandel: SMART has some OAuth profiles (+ thoughts) that might be a good fit if we want to specify how authorization works. [9/05/2014 5:06:41 PM] Josh Mandel: I'm not sure how much depth/complexity you're envisioning...[9/05/2014 5:07:14 PM | Edited 5:07:21 PM] Grahame Grieve: Josh - we also agreed to publish a set of recommended security profiles with conformance points for different use cases. What you're talking about fits more into that

[9/05/2014 11:53:22 PM] David Daniel: I would lean more to claims than roles and permissions. That seems to fit better to me for a distributed and integration model. It is also used by more of the recent internet security mechanisms like openid connect and wsfederation

[9/05/2014 11:57:27 PM] Grahame Grieve: claims are for sessions, no? You still hve to resolve to managed users with roles?

[9/05/2014 11:59:15 PM] David Daniel: When I think of a claim I kind of think of it similar to a permission or attribute that is associated with an identity. So my user may have logged into google and google says I have a claim of email=ddaniel@4ddsoftware.com and a claim of labcreator

[9/05/2014 11:59:51 PM] David Daniel: Now if I am also logged into facebook then facebook can either accept googles claims of or transform them.

[10/05/2014 12:01:19 AM] David Daniel: It could say I will let you create a lab because I trust googles lab claim but you will get a secondaryemail claim of ddaniel@4ddsoftware.com and your primary cliam of email will be ddaniel@facebook.com

[10/05/2014 12:02:45 AM] David Daniel: So all claims are signed by the identity server that generates them and the implementation decides who's claims they trust and how they are handled

[10/05/2014 12:03:00 AM] Grahame Grieve: how do they decide that? that's the bit we're interested in here

[10/05/2014 12:04:57 AM] David Daniel: The specs dont generally go much into that because it is so implementation dependent. They go into signing claims and transerferring them but I have not seen to many that have a definition for how to handle that low in the implementation

[10/05/2014 12:05:54 AM] David Daniel: For .net there is a really good open source identity server that I tend to use when writing custom security providers that may give you some ideas if you take a look at.

[10/05/2014 12:06:23 AM] David Daniel: https://github.com/thinktecture/Thinktecture.IdentityServer.v3

[10/05/2014 12:06:42 AM] David Daniel: that is the latest version

[10/05/2014 12:07:05 AM | Edited 12:07:09 AM] Grahame Grieve: well, this time, we are looking at that implementation part

[10/05/2014 12:08:06 AM] James Agnew: These seem like orthogonal bits- claims/attributes are useful, but it doesn't seem like it would be useful to replicate/replace OAuth2/SAML/etc in FHIR. Those specs should work fine in harmony with FHIR. Presumably the resources on discussion here are more around user management? as opposed to runtime service authorization?

[10/05/2014 12:08:42 AM] Grahame Grieve: y. this is about user management, because some people want to be able to do that

[10/05/2014 12:09:27 AM] David Daniel: I was not trying to suggest a route for a security implementation and I am sorry it came accross that way

[10/05/2014 12:09:46 AM] James Agnew: This is a hot topic for me right now, we're trying to get OAuth2 working with FHIR.. Josh, I really need to dig into how you are doing this with SMART. :)

[10/05/2014 12:09:50 AM] Grahame Grieve: for instance, on my autheticated interface, I accept OAuth logins, but I want to expose an interface for you guys to manage your own premisions on my server

[10/05/2014 12:10:15 AM] Grahame Grieve: James, have you looked at my server /secure - I show a different aspect

[10/05/2014 12:10:43 AM] James Agnew: i haven't and I clearly should!

[10/05/2014 12:10:59 AM] David Daniel: I was more advocating for a model that can handle those. Microsofts user for example that is currently used to handle those is IClaimsPrinciple http://msdn.microsoft.com/en-us/library/microsoft.identitymodel.claims.iclaimsprincipal.aspx

[10/05/2014 12:11:06 AM] Grahame Grieve: http://fhir.healthintersections.com.au/closed

[10/05/2014 12:11:14 AM] Grahame Grieve: I see the OAUth parts are not go :(

[10/05/2014 12:11:21 AM] Grahame Grieve: I will get them going later today

[10/05/2014 12:12:50 AM] James Agnew: Grahame, what credentials would be used to test that out?

[10/05/2014 12:13:03 AM] Grahame Grieve: I accept logins from google, facebook, and HL7

[10/05/2014 12:13:20 AM] Grahame Grieve: or inbuilt, which is presently broken waiting for a user management system ;)

[10/05/2014 12:13:22 AM] Josh Mandel: In SMART we're doing/advocating something like: https://groups.google.com/forum/#!topic/smart-on-fhir/RtjkVM_xdT8

[10/05/2014 12:13:57 AM | Edited 12:14:01 AM] Josh Mandel: Useful parts to have in FHIR woud be: more general than a "user," to have a "principal" that could be a user or an app/service that had permissions to access data.

[10/05/2014 12:14:14 AM | Edited 12:14:17 AM] Josh Mandel: This would allow us to list apps, etc, without having to define resources outside of FHIR.

[10/05/2014 12:14:24 AM] Grahame Grieve: + I like that

[10/05/2014 12:15:13 AM] James Agnew: David, what would that look like? Not disputing the utility at all, (and IAAA is not my strongest subject) We've actually used Thinktecture on a project here oddly enough, and as far as I can see it shouldn't require anything new to send tokens from that STS in HTTP headers over..

[10/05/2014 12:17:00 AM] James Agnew: + me too

[10/05/2014 12:17:40 AM] David Daniel: Since we are just really trying to define the objects that may get stored my suggestion was to just take a look at the objects that are used currently to get some ideas. I really only know about it on the .NET side where there are claims and claims principals and that was was I was advocating over users, permissions and roles.

[10/05/2014 12:18:53 AM] David Daniel: Thinktecture has done some work on creating userproviders and claimsproviders that may give some ideas for how to pull them into code but I think the base objects are the most important because they will need to be compatible with the more popular security standards

[10/05/2014 12:20:05 AM] David Daniel: People will want to be able to integrate them their repositories whether it be ldap, active directory or custom

[10/05/2014 12:20:37 AM] David Daniel: You will want to make sure they are robust enough to handle easy integration

[10/05/2014 12:22:51 AM] Grahame Grieve: I'll have a look next week

[10/05/2014 1:08:35 AM] Peter Bernhardt: @james ... that's right - Thinktecture supports OAuth

[10/05/2014 1:09:00 AM] Peter Bernhardt: so does PingIdentity

[10/05/2014 1:09:14 AM] Peter Bernhardt: sure there are others out there that are also OS

[10/05/2014 1:19:06 AM | Edited 1:19:24 AM] Josh Mandel: Sure, we've been using MitreID Connect. There's also ForgeRock. And Gluu.

[10/05/2014 2:06:53 AM] John Moehrke: There are two different use-cases that we intend to enable: (1) simplistic user/role/permission management for low-scale use, where no formal IAM is going to be used; (2) for those that are using formal IAM (OAuth, OpenID Connect, SAML, or LDAP), enable bridging of user/role as managed in the IAM with healthcare specific permissions and authorizations (consents).

[10/05/2014 2:07:22 AM] Grahame Grieve: y. agree with that

[10/05/2014 2:07:23 AM] John Moehrke: For (2) there is some work to leverage from IHE in the IUA profile that we already point at; but does need some FHIR bridging

[10/05/2014 2:15:22 AM] Peter Bernhardt: what kind of bridging? specification of claims - like NHIN Auth framework? or more?

[10/05/2014 2:19:14 AM] Grahame Grieve: mapping between claims and roles, I assumed osh meant

[10/05/2014 2:25:19 AM] John Moehrke: yes, when using an external IAM, one needs to be able to relate that federated identity to your resource permissions/authorizations. Can be as simple as a dynamically created user account, with automatically provisioned roles, that have assigned permissions. Once this account exists, one might need to modify it over-time.