Trusted Architecture for Secure Shared Services (with Privacy) - PowerPoint PPT Presentation

TAS 3 Trusted Architecture for Secure Shared Services (with Privacy) Sampo Kellomäki (sampo@zxidp.org) 29. September, 2010, ICT, Brussels 05

TAS 3 Intro • Visit TAS 3 booth in hall H (near Prime Life booth) • Project runs until end of 2011 • Architecture - Identity Management, Authorization, and Audit plumbing - Holistic combination of existing technologies • Protocol Profiles (SAML2, ID-WSF, XACML, ...) • Reference Implementation in open source - zxid.org (Apache2 non-viral license) • Vision of empowering users and building trust networks - Internet of Subjects Foundation - Competitieve Services Market Place - Delegation - Trust scoring and trust building September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 2

Empowering user to take control of his data • Fully Pair-wise pseudonymous design - Prevent correlation and collusion • Model where user gives his data from his Personal Data Store - User well positioned to impose policies when releasing data - Only store data once, and in place that user chooses • Personas, partial identities • User self audit dashboard gives user visibility to use of his data - Independent means, to keep the service providers in check • Digitally signed audit trail to ensure legal enforeability September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 3

TAS³ Architecture Mini 2010 User is King Identity Provider (Authentication) = Access Controll and Authorization "Front Channel" SSO Self-audit Web Site 2 Web Site 1 Dashboard "Backchannel" Personal Service O Discovery C Web Service 4 Web Service 3 T Trust, Scoring, and Reputation Web Service 5 Audit (comprehensive and ecosystemwide) Governance & Interoperable Technology September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 4

TAS3 Architecture 2010 Web Browser or Fat Client Client side app (e.g. AJAX) Component Overview v2.3 Organization Domain Runtime & Enforcement Modelling Payload Applications Core TAS3 Infrastructure TAS3 User Tools & Config. Mgmt User Audit Front End Identity Provider Trust Dashboard (e.g. Web GUI) Network Mgmt Business Process Policy Editor & Identity Processes Engine Consent Management Aggregator Config. Web Services Delegation Settings Trust & Reputation Data Biz. Proc. Models Core TAS3 Infrastructure Backchannel Policies Authorization Delegation Service ID Mapper Modelling Credentials & Policies Discovery Registry Ontology Handler Tools Negotiator Org. Level Event Bus Audit Events Management Events Ontology Audit & (Operation Monitoring) (Audit Analysis) Online Compliance Testing Monitor September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 5

Built-in rules of the application Built-in rules of the service Service Client App Rules of the operator Rules of the operator Org D PDP Org C PDP Alice Bob TN PDP PEP Rs Out Rules of the TN PEP 1 2 Master Master Rq Out 4 3 PDP PDP Trust PDP PEP PEP Rq In Rs In Alice PDP Bob PDP Personal rules Personal rules Corp D Firewall Corp C Firewall 20100531 Sampo or Packet Filter or Packet Filter September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 6

XACML SAML profile TAS3 Integration w/ZXID zxididp zxididp with TAS3 Trust extensions 20091016 SK SAML 2.0 TUE Discovery Trust PDP IdP 3 ID-WSF 2.0 Discovery with TAS3 Trust SP1: Frontend SP2: Web Service extensions Inter- Payload 1 ceptor Servlet CTX DB Inter- ID-WSF 2.0 7 JSESSION ceptor w/TAS3 ext ZXSES H A H WSPout PEP-rs-out P P W e S s e D P P T T t E E S t I S E e t E 2 T T t P P c C O P s c P C WSPin PEP-rs-in P r P User XACML SAML profile zxid_az() zxid_az() mod_auth_saml ZXID zxid_call() or ssoservlet ZXID zxid_wsp_decorate() Servlet AXIS2 Master Master KENT zxid_simple() KENT Filter PDP2 Module PDP1 zxid_wsp_validate() September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 7

Promotors TAS 3 - Trusted Architecture for Securely Shareable Services Core Security Architecture IoS - Internet of Subjects Trust Convener and Ecosystem Builder ZXID Reference implementation of the TAS 3 Core Security Arch. Core Standards • OASIS SAML 2.0 • Liberty Alliance ID-WSF 2.0 & Data Services Template (DST) 2.1 • OASIS XACML 2.0 Access Control • IoS and TAS 3 : Personal Data Store (PDS) Specification • Sector specific data schemas • Metadata standardization still TBD September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 8

IoS 7 Rules 1. Personal Control 2. Searchability 3. Instant Social Networking 4. Ubiquity 5. Symmetry 6. Minimization 7. Accountability September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 9

Big 4 of Privacy Protection (Seda et al. ) 1. Awareness: Self audit (dashboard), Identity mirrors 2. Confidentiality - Consent to release - Reputation based screening, Trust and Privacy Negotiation - Cryptographic protection - Avoidance of correlation handles (prevent illicit collusion) 3. Control - Intended purpose & Audience restrictions - Sticky policies - Policy enforcement & Audit 4. Practise - Right to correct and delete, Right of response - Trust and reputation feedback - Send strong positive signal of your own

IoS Concepts • IoS - IoS compliant Business Services - IoS Infrastructure - Dashboards - Shared WS: AIM, calendar, directories, harvesting, publication, ... - Personal data service(s) + dashboard (one or per service?) - Symmetry in providing services - Every user can become a Service Provider • Personal - Communal - Public • Separation of data from services • Mostly pull and as-needed communication (minimization) September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 11

TAS3 Recursive Call Demo 3 (yk) 20100219 sampo@symlab.com IdP Discovery 7 2,4 5 1 WSP WSP User FE (wspdemo) (wspleaf) (browser) (appdemo) 8 6 PDP September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 12

TAS3 Delegated Web Service Access v02 20100922 sk IdP Deleg IDMap DiscoA 1 PDP Frontend SP1 Normal use of service by Alice WSP2 Alice Alice delegates (Job seeker) and invites 7 8 2 5 4 6 1. ps:AddEntityReq 1. Generate invitation 2. 2. Send invitation 3. 3. Bob accesses SP1 Bob uses invite 3 4. ps:ResolveIdentifierReq 4. Resolve invitation to get delegated to DITokA + perms access to Alice’s 5. im:IdentityMappingReq 5. Map Bob1 to BobDIA service 6. di:Query 6. Discover WSP2A Bob 7. im:IdentityMappingReq 7. Map Bob1 to Bob2 (Coach) 8. 8. Call WSP2 September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 13

Delegation 1. Generate invitation - Assign invitation ID for management of invitation - Set up permissions for what resources invitee can access - The permissions can be keyed on invitee’s identity, or - they can be keyed on the invitation ID 2. Send by out-of-band means, such as email or IM. The invitation will be formatted as a URL. 3. When Bob (being the invitee) clicks on the URL, he lands on Fron- tend site (alternatively Bob could land on WebGUI aspect of the Delegation server site) - The site forces Bob to SSO (if this did not happen, invitation would be a bearer token) 4. The invitation is resolved to Discovery Token of Alice (the inviter) September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 14

- The token contains as an attribute the invitation ID (the token is encrypted so that only the discovery service of Alice can open it, therefore the invitationID itself does not become a correlation handle). - Basically the discovery token of Alice would allow Bob to dis- cover any service of Alice. As this is not desired, it is constrained by the permissions set at step 1. - Problem: how does SP1 accessed by Bob know where Alice’s Delegation Service is located? This would be obvious if the URL points to the Delegation service of Alice. 5. For Bob to be able to call Alice’s discovery service (next step), Bob needs to present his own identity token to DiscoA. This is obtained by calling Bob’s ID Mapping service. 6. Bob discovers Alice’s WSP2. This is permitted by permissions. 7. For Bob to be able to call Alice’s WSP2 (next step), Bob needs September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 15

to present his own identity token at WSP2A. This is obtained by calling Bob’s ID Mapping service. 8. Call to WSP2A is made with Alice’s token from step 6 as TargetIdentity SOAP header and Bob’s token from step 7 as wsse:Security/Token. Ideally WSP2 would also have permissions indicating that the dele- gation from Alice to Bob is valid. This could be arranged by WSP2 making a call to Delegation service to confirm the delegation. Un- fortunately such confirmation API is not specified by Liberty. We could invent an API. Another approach would be to at step 1 to provision the policies to PDP of WSP2. September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 16

TAS³ Architecture Mini 2010 User is King Identity Provider (Authentication) = Access Controll and Authorization "Front Channel" SSO Self-audit Web Site 2 Web Site 1 Dashboard "Backchannel" Personal Service O Discovery C Web Service 4 Web Service 3 T Trust, Scoring, and Reputation Web Service 5 Audit (comprehensive and ecosystemwide) Governance & Interoperable Technology September 29, 2010 Sampo Kellomäki: TAS3 Architecture 05 17