1 / 11

Cross-Enterprise Privacy Policy (XPP) - revised -

Cross-Enterprise Privacy Policy (XPP) - revised -. Profile Proposal for 2008/09 presented to the IT Infrastructure Technical Committee Kuhlisch, Caumanns, Rode (eCR, Fraunhofer ISST) November, 19th 2008. Actors and Transactions. 1. Transaction 1: Resource Access. request comes with:.

bud
Download Presentation

Cross-Enterprise Privacy Policy (XPP) - revised -

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cross-Enterprise Privacy Policy (XPP)- revised - Profile Proposal for 2008/09 presented to the IT Infrastructure Technical Committee Kuhlisch, Caumanns, Rode (eCR, Fraunhofer ISST) November, 19th 2008

  2. Actors and Transactions 1

  3. Transaction 1: Resource Access request comes with: XUA(policy pull) XUA, Access Assertion(policy cache) XUA, Access Assertion, Policy Assertion(policy push) PT – Protection Token ST – SupportingTokens

  4. Actors and Transactions 2

  5. Transaction 2: PD request • Integration of PDP and PEP should not be specified as an explicit transaction • Advantages: • message flow between PDP and PEP can be implementation specific and  the profile does not set restriction on the attributes exchanged and the policy encoding used  profile complexity is minimized But: The XPP Access Control Interceptor must support at least one policy encoding (e. g. XACML)

  6. Actors and Transactions 3

  7. Transaction 3a: requestAccessAssertion • SOAP based communication (WS Trust  RST/RSTR) RST: • Security Header: (SAML Token) • XUA Assertion (Subject information) • Body: (CustomExchange element) • Resource • Action  e.g. encoding as XACML request RSTR: • Body: (RequestedSecurityToken element) • Access Assertion (contains policy reference) • Policy Reference Encoding: • e.g. XACML Policy(Set)IdReference

  8. Transaction 3b: requestPolicyAssertion • SOAP based communication (WS Trust  RST/RSTR) RST: • Security Header: (SAML Token) • XUA • Access Assertion (Policy Reference information) • Body: (CustomExchange element) • requested Policy Encoding RSTR: • Body: (RequestedSecurityToken element) • Policy Assertion (contains concrete policy in requested encoding) • Policy Encoding: • e.g. XACML, P3P, EPAL, ...

  9. Conclusion (1/2) • For the eCR it took 18 month of discussion to get to the solution as proposed with this profile proposal • Performance is an issue • Lessons learned at Siemens with their eCR implementation • About 145 forum interactions between the Siemens development team for eFA security and the WSIT team at Sun over 6 months. About 10 bugs were reported [and fixed by SUN]. • We did not get the impression that other projects worldwide were burdening the properties of this WS-stack to the same degree as we had to do.

  10. Conclusion (2/2) • Federated authorization is an issue for cross-domain XDS • But: Federated authorization is still not well understood • And: Decoupling (authentication and) authorization from business services (actors) is not state-of-the-mind in healthcare IT • BUT: • With XUA IHE is on a very good way towards a state-of-the-art security infrastructure based on the paradigms of SOA security • XPP is the logical next step

  11. Suggestion • White Paper: Authorization for IHE ITI Profiles • motivation and use cases • cross-domain (federated) authorization • IHE ITI authorization framework • data flow (policy push vs. policy pull) • PEP, PDP, PAP, PIP deployment and integration • provider-enforced BPPC • safeguarding IHE transactions (cookbook) • Profile: Policy Provisioning (XPP) • transactions 3a/3b (PAP interaction) • Profile on SAML and WS Trust • Profile: XDS Access Control Policies • XACML profile for safeguarding XDS actors andresources

More Related