Discover Service Sequence diagram (Directed Exchange to an Unknown Address use case)

1. Discover Service Sequence diagram (Directed Exchange to an Unknown Address use case) How do we technically authorize the requestor ? Request originates from a system, not a user (System to System Verification)

2. Discover Service Sequence diagram (Directed Exchange to an Unknown Address use case) • Technical Issues to discuss: • Authentication vs Authorization • Authentication identifies who the requestor is. • Typically authorization follows authentication to provide limited access. • Impact on D&TS: • Authentication is important so that we don’t get queries from unknown requestors (Organizations not on-boarded to the State D&TS). • Authorization is important so that D&TS will just provide access to the Interface (API) to search for the provider but nothing else. (Things that would not be accessible are the directories and other metadata and other interfaces that may exist).

3. Authentication / Authorization Options: • Option #1: Mutual TLS Authentication • Authenticate the Requestor (client) and the Service provider (D&TS) • No authorization, but authorization can be controlled in other ways using what web services are exposed etc. • Mechanics at a high level: • Step 1: Client tries to request the service from the service provider • Step 2: Server presents it’s certificate and requests certificate for client • Step 3: Client presents it’s certificate and proves it has the private key • Step 4: If these certificates are from trusted roots (same root) then they are good and establish a TLS encrypted communication channel. • Summary: The communication links at either ends are authenticated to be valid entities that are trusted by both parties. • Pros: • Simple to implement, happens at the transport layer. • Cons: • Mutual TLS works when all the clients and servers are rooted to a single CA. • This is being enhanced with SNI but that is not adopted widely. • DIRECT Blog Post explaining all the limitations that we encountered long time back. • http://news.avancehealth.com/2010/12/smime-and-tls-directproject.html

4. Authentication / Authorization Options: • Option #2: Using SAML • XML Standard from OASIS to convey authentcation / authorization information between security domains (Domains are essentially organizations that manage their own security services) • For e.g KP may have a single domain although they operate in multiple regions. • It is also possible that they have multiple domains if KP chooses in which case a Provider logged into the SCAL domain may not be able to access information from the CO domain because the identities are not shared across them. • SAML has been profiled for use in NwHIN using SOAP Web Services • WS – Security standard to package the SAML Token / Assertion • WS – Trust to request tokens • NwHIN Messaging and Authorization based on SAML Assertions • Flexible standard that can be used in a standardized manner across organizations but complex to implement • One of the reasons NwHIN participants struggle during implementation of specs and on-boarding • Supports tokens based on LDAP / PKI and other standards

5. Authentication / Authorization using SAML Cont’d: 1. The client requests a security token to communicate with the STS in the target security domain. The client presents authentication credentials, a security token previously issued by the STS, or a security token issued by another trusted authentication broker to obtain the security token for the target security domain. 2. The STS in the client's domain validates the credentials or security token presented by the client. The STS in the client's security domain may make authorization decisions about whether to issue a security token to the client for use in the security domain where the target service operates. 3. The STS in the client's domain issues a security token to the client that is used to obtain a service token from the STS in the domain where the target service operates. If the client is authenticated and authorized by the STS in the client's domain that STS issues a security token to the client to communicate with the STS in the target domain where the Web service operates. Based on the target security domain, the STS in the client's domain knows the type and scope of security token to issue. 4. The client requests a security token from the STS in the target security domain. The client presents the token issued by its STS to communicate with the STS of the target security domain. 5. The target STS validates the client's security token. The STS in the target security domain verifies that the token presented by the client originated from an STS in a trusted security domain. After the STS in the Web service's security domain validates the security token presented by the client, it may make an authorization decision about whether the client is authorized to access the requested service. 6. The target STS issues a security token to communicate with the service. If the target STS decides that the request is valid and the client is authorized to communicate with the service, it will issue a security token to the client that can be used to communicate with the service. 7. The client sends a request message to the service. The client attaches the security token it received from the STS in the target service's security domain to the request and sends it to the service. 8. The service validates the security token attached to the request. The service verifies that the token presented by the client was issued by a trusted STS. 9. The service initializes and sends a response message to the client.

6. Authentication / Authorization Options using SAML Cont’d:

7. Authentication / Authorization Options using SAML Cont’d: • Summary: • Flexible, Robust standard • Supports UserName + Pwd, Kerberos • LDAP attributes • PKI, Smart cards etc. • Complex to implement (especially by smaller organizations) • Most organizations don’t have a real STS Server • Generating SAML Assertions based on other mechanisms requires a good understanding of the Specs. • D&TS will have to maintain a list of trusted certificates to be used to validate that the organization sending the request is on-boarded • https://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf

8. Authentication / Authorization Options: • Option #3: Using Oauth 2.0 • Used extensively in the Internet (e.g Google, Facebook etc) • Most RESTful interfaces use this as their mechanisms. • Not as standardized as SAML for Healthcare • S&I Framework initiative (RHEx) starting today to work on the feasibility • Allows external organization access to internal resources • Based on tokens • Tokens can be issued for specific services for specific times and so on • Similar to Valet Key to allow limited access • Resource Owner (D&TS) can grant access to requestors offline using various mechanisms • Such as use a registration website to collect information and provide some token. • http://tools.ietf.org/html/draft-ietf-oauth-v2-27 • http://hueniverse.com/oauth/guide/workflow/

9. Authentication / Authorization Options using Oauth Cont’d: A. Authorization Request Client Resource Owner B. Authorization Grant C. Authorization Grant Authorization Server D. Access Token E. Access Token Resource Server F. Protected Resource The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary. (B) The client receives an authorization grant which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server. (C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant. (D) The authorization server authenticates the client and validates the authorization grant, and if valid issues an access token. (E) The client requests the protected resource from the resource server and authenticates by presenting the access token. (F) The resource server validates the access token, and if valid, serves the request.