Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2019 | Authentication & Authorization for Clinical Microservices | Identiverse | Day 1, June 25

157 views

Published on

One of the challenges facing micro-services architecture in the clinical space is developing patterns defining various levels of authentication and authorization for your patient record APIs. Our approach was to use the current identity standards, OIDC and Oauth, as well as ABAC, to create 3 levels of authorized access to our clinical micro-service APIs.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

2019 | Authentication & Authorization for Clinical Microservices | Identiverse | Day 1, June 25

  1. 1. ® AUTHENTICATION & AUTHORIZATION FOR CLINICAL MICRO-SERVICES
  2. 2. ® Overview Protecting Clinical APIs
  3. 3. ® Use Cases • Deployment of a genomic medicine service for the routine request of a patient’s whole genome sequence initially focusing on rare diseases and cancers. • Multiple types of users • Clinicians – taking samples, entering tests request, family history. • Doctors – requesting tests, specific genome panels, and reviewing results. • Researchers & scientist – actual sequence work, interpretations, genome research. • Multiple types of locations • Hospitals, labs, clinics, research institutes.
  4. 4. ® Application Architecture • Micro-services based applications • All services containerized • RESTful APIs • API Gateway protecting all micro-services
  5. 5. ® MicroServices UI Testing Pedigree Reporting Records Kong API Gateway Clinician UI Doctor UI Scientist UI Researcher UI Database
  6. 6. ® Authentication & Authorization Requirements and Solutions
  7. 7. ® Authentication & Authorization Considerations • Existing clinicians in Azure o365 tenant. • Stick to standards (OIDC, Oauth, XACML). • There are UI and back-end services (in front of API Gateway and behind API Gateway) that must be authenticated. • Abstract security as much as reasonable from microservice via Gateway. • Multiple levels of authorization allowed – coarse to fine. • Must be fast (Authorization handled within kubernetes namespace)
  8. 8. ® Authentication • Create new Azure AD tenant and allow existing clinicians as B2B guests. • Create groups in azure AD for RBAC authorization rules. • UI configured to use OpenID Connect client with Azure as the OpenID provider. • Custom auth plugin for Kong API Gateway for OIDC integration with Azure AD IDP. • YubiKeys for 2FA.
  9. 9. ® Authorization – Coarse (RBAC) • Azure AD defined roles are included in ID_Token as claims. • Claims are used to define which medical APIs and what actions a clinician is allowed to access. • Kong custom auth plugin can also service RBAC controls. Simple Authorization rules can be enforced with white and black lists. • Kong Authorization Policy • <http_verb>_allow = role1, role2… • <http_verb>_deny = role9, role10…
  10. 10. ® Authorization – Coarse (Example) Clinician Carlos is trying to lookup a patient record. GET /patient-record/{record_id} Carlos is allowed access as long as he has the correct group membership (ClinicianRole). Subject + Verb + Object
  11. 11. ® Authorization – Coarse (Example) /patient-record/{record_id} Auth-Plugin config.whitelist = GET=clinicianRole • Verb-specific whitelist rules. For example: GET=role1 or when specifying multiple roles (colon-separated role names), GET=role1;role2. For defining multiple verb-specific roles, this can be defined as (multiple verb specific rules can be separated by comma)- config.whitelist=GET=role1;role2,POST=role3;role2,DELETE=role_ad min
  12. 12. ® Authorization – Fine (ABAC) • Centralize ABAC policy. • Limit impact to clinical microservices. • Limit re-deployments based on policy changes. • Enforce at API Gateway most preferable. • Lightweight solution.
  13. 13. ® Authorization – Fine (ABAC) • Axiomatics access decision service deployed as microservice within the kubernetes namespace for fine grain authorization decisions. • Custom Axiomatics Kong Plugin developed to make REST call to Axiomatics ADS to give decision based on claims and additional back-end relationship database.
  14. 14. ® Authorization – Fine (Example) Clinician Carlos is trying to lookup a patient record. GET /patient-record/{record_id} Carlos is allowed, as long as he has the right access group AND he has a clinical relationship to the patient. Subject + Verb + Object + Context
  15. 15. ® Authorization – Fine (Example) /patient-record/{record_id} Auth_Plugin config.whitelist = GET=clinicianRole Axio_Plugin config.claims_to_include = groups, roles,… • Kong plugin collects the claims and sends a POST to the Axiomatics REST API endpoint (ADS microservice). • ADS microservice is the decision point that applies the policy and returns an Allow/Deny decision.
  16. 16. ®
  17. 17. ® Creating and Deploying Fine Grain Policy
  18. 18. ® Create Policy Axiomatics Service Manager Patient Record DB PIP Connector Only used for policy creation via UI. Not used during actual policy enforcement. ALFA (Abbreviated Language for Authorization) is an available plugin for Eclipse to allow for standalone policy creation as an alternative to using the ASM.
  19. 19. ® Export Policy into ConfigMap Axiomatics Service Manager PIP Connector OpenShift / Kubernetes ADS ConfigMap
  20. 20. ® Deploy ADS Microservice Patient Record DB ADS Microservice ads.jar OpenShift ADS ConfigMap
  21. 21. ® Multiple Policy Domains Support ADS Microservice ads.jar ADS Microservice ads.jar Attribute DB ADS Microservice ads.jar Policy1 ADS ConfigMap Policy2 ADS ConfigMap ADS Microservice ads.jar Attribute DB
  22. 22. ® Lessons Learned • Engage development teams early. Do heavy lifting. • Developer adoption decides success / failure of project. • Educate on architecture approach. REST API, not legacy WSDL • Understand their APIs. (Swagger UI) • Focus on business requirements. • Don’t try to solution policy without getthing the business uses cases first.
  23. 23. ® Open Source • Azure IDP OIDC Kong Plugin • https://bitbucket.org/gt_tech/jwks_aware_oauth_jwt_access_tok en_validator • Axiomatics Kong Plugin • https://github.com/ioannis-iordanidis/kong-axiomatics-plugin • Additional Kong Plugins • https://github.com/optum
  24. 24. ®

×