tas3 architecture - zxidzxid.org/tas3/sampo-tas3-arch-servicewave-stockholm-slides-2009.pdf ·...

TAS3

Architecture

Sampo Kellomäki ([email protected]), Symlabs

23.11.2009, ServiceWave, Stockholm

The research leading to these results has received funding from the European Commu-

nity’s Seventh Framework Programme (FP7/2007-2013) under grant agreement num-

ber 216287 (TAS3 - Trusted Architecture for Securely Shared Services - www.tas3.eu)

10

TAS3 Project (48 months, 2008-2011)•Goals- Trusted Architecture for Securely Shareable Services- Web Services made secure, privacy friendly, and shareable- Dashboard for user’s privacy settings and self audit- Full audiability, leverage digital signatures- Advanced Trust and Privacy Negotiation and Trust Scoring- Business and legal model

• Practical- Standards based (SAML, ID-WSF, XACML) interoperable wirespecs- API (Java, C#, PHP, Perl, C/C++)- Reference implementation (zxid.org)- Pilots- Exploitation: buy TAS3 enabled components from vendors suchas Symlabs, Risaris, Custodix, and Synergetics

23.11.2009 Sampo Kellomäki: TAS3 Arch 10 2

Modelling &configurationManagement


Runtime &Enforcement

Model

Audit

Audit & Monitor

TAS3 Trust Network Domains

Organization A Domains...

Organization B Domains


Front channel and back channel interactionTAS3 TN Model

TAS3 TN Compliance, Audit, and Monitor

Audit & Monitor Audit & Monitor

Modelling Modelling

Org BOrg A(Context A) (Context B)

Runtime

IdP B

IDMap

Back ChannelWeb Services

Layer

DashBFE A1

Az

Az

WS B1

Az

Az

WS A2

Az

WS B2

Az

Re B

Front Channel, Web GUI Interaction

Authentication

1

2, 4

3

56

7, 9

810


Audit ChannelTAS3 TN Model



Modelling Modelling


Runtime

IdP B

IDMap


Layer

DashBFE A1

Az

Az

WS B1

Az

Az

WS A2

Az

WS B2

Az

Re B


Authentication

1

2, 4

3

56

7, 9

810

e4

e5

e6

e7,e9

e8

e10

e3

AuditEventBus

LogMon


Model driven configurationTAS3 TN Model



Modelling Modelling


Runtime

IdP B

IDMap


Layer

DashBFE A1

Az

Az

WS B1

Az

Az

WS A2

Az

WS B2

Az

Re B


Authentication

1

2, 4

3

56

7, 9

810

ModelModel


Model driven audit

Modelling and Configuration Management Domain Runtime and Enforcement Domain

Audit and Monitoring Domain

Automatically pushconsistent securityconfiguration

Discover usage& configuration

ModellingTool

Models andconfigurations

Auditing &ComplianceTools

OperationMonitoring

Frontend Services

Middletier Web Services

Backend WS

Dashboard

IdP

Disco* *

* * ===

= = =

= =

TAS3 CoT Model

Connectors

= Routing &

aggregation

= PEP

*=

Use model to drivevisualization of workflowand system


Dashboard

Audit

Identity Provider

Operation Monitoring

Modelling &ConfigurationManagement

Runtime & Enforcement

Audit &Monitor

Organization Domain

Compliance Validation

Delegation

Infrastructure

Authorization

IDMapper

Trust & PrivacyNegociator

Registry Server

Discovery

Trust Reputation

Trust NetworkProcess Manager Linking

Event BusAudit Management

Front EndServices

Business processEngine

Web Services

Payload

ClientApplication

Web BrowserR

R

Dashboard

RR

R


IdP Discovery

SP1: Frontend SP2: Web Service

MasterPDP1

MasterPDP2

User

Trust PDP

HTTP

WSC

PEP

SSO

Attr

PEP

etc

PayloadServlet

PEP

ses

JSESSION

ZXSES

HTTP WSPin PEP-rs-in

WSPout PEP-rs-outetc

DB

Inter-ceptor

Inter-ceptor

PEP

XACML SAML profile

XACML SAML profilewith TAS3 Trust extensions

ID-WSF 2.0Discoverywith TAS3 Trustextensions

DIC

ID-WSF 2.0w/TAS3 ext

SAML 2.0

CTX1

2

3

7


Prior Art and Reference Architectures• TAS3 Architecture draws from and is compatible with- Nessi’s NexofRA-Master’s concept of audit bus and Awareness Cockpit- Access-eGov Platform Architecture- Liberty Alliance’s ID Web Services Framework (ID-WSF)- Hafner & Breu’s Security Engineering for Service-Oriented Archi-tectures

• TAS3 Architecture is not as abstract as a reference architecture- Goal is to drive real interoperable implementations


Novelty of the Architecture Itself (1/2)• TAS3 Architecture is novel as a blueprint that brings together- Identity management- Attribute based access control- Business process modelling- Dynamic trust- Distributed auditing- Legal & Policy- Support for multiple policies in different languages- Annex A in combination with D2.2, acts as an interoperabilityprofile for standards based protocols covering these areas

•User transparency features- Dashboard- User accessible audit trail- Automated compliance validation


Novelty of the Architecture Itself (2/2)• Privacy protection using sticky policies•Marriage of Trust and Privacy Negotiation with discovery and trustscoring

• Secure dynamic business processes• Built-in first class support for delegation• Architecture needs to be instantiated in context of a businessmodel and legal / contractual framework- Leave many decisions to be decided in that context- Many business models are possible (the one currently in annexwill become a document of its own)


Wire interoperability, manysoftware implementations possible• Any implementation that speaks wire protocols and flows cor-rectly is valid, irrespective of the software architecture

• Software architecture of the entities specified by the TAS3 Archi-tecture is up to implementers of those entities (some of the im-plementer’s are TAS3 work packages)

• The architecture includes a legacy integration strategy to illus-trate some feasible ways to TAS3 enable existing applications (butwhich way is chosen, or if a totally different software architectureis used, is an implementer’s choice)


Trustworthy and Secure (1/2)•Operational, legal, and business model to ensure trustworthiness- Responsible entity, Trust Guarantor, ensures "buck stops here"- Legal framework developed hand-in-hand with architecture- Certification of software and deployments- Automated Compliance Validation keeps SPs in line- Manual audits complement automated approaches- Modeling network and its members provide consistent securityconfiguration

• Legal concerns are built-in from the ground up• Threat analysis to understand what we are defending against


Trustworthy and Secure (2/2)• Technical- Fully encrypted, fully digitally signed- Fully pseudonymous design ensures maximum privacy- Fully cross organizational federation model- Explicit tokens based audit trail at all layers- Explicit authorization at all layers- Advanced trust and reputation management- Model and ontology driven to ensure accurate implementation


Deploying TAS3 Architecture• Set up Trust Network- Draft legal- Run some services, like audit bus and compliance validation- Outsource or run other services like discovery and IdP

• Join a Trust Network- Much of the infrastructure shared or already provided- Application integration- Buy and deploy TAS3 proxy or connector product, or- Adapt your application using TAS3 Standard API.- Outsource or buy/run some infrastructure services like IdP orPDP


Thank You, Questions?Sampo Kellomäki ([email protected])+351-918.731.007

• www.tas3.org- Official dissemination website

• http://zxid.org/- Reference implementation of TAS3 Core Security Architecture

• http://zxid.org/tas3/- ZXID specific TAS3 news

• http://zxid.org/tas3/arch/tas3-deliv-2_1-arch-v17_2.pdf- TAS3 Architecture Document

• http://zxid.org/tas3/arch/tas3-proto-v06.pdf- Revised TAS3 API and protocol profiles


Architecture Drilldown



Runtime &Enforcement

Model

Audit

Audit & Monitor

TAS3 Trust Network Domains

Organization A Domains...

Organization B Domains


Dashboard

Audit

Identity Provider

Operation Monitoring

Modelling &ConfigurationManagement

Runtime & Enforcement

Audit &Monitor

Organization Domain

Compliance Validation

Delegation

Infrastructure

Authorization

IDMapper

Trust & PrivacyNegociator

Registry Server

Discovery

Trust Reputation

Trust NetworkProcess Manager Linking

Event BusAudit Management

Front EndServices

Business processEngine

Web Services

Payload

ClientApplication

Web BrowserR

R

Dashboard

RR

R


Web Service Authorization

Front End Service

Web Application

WebGUI

R

Service Requester

PEP Out PEP In

Stack

InfrastructureAuthorization

RR

RR

R

LegendWeb Service

Service Application

Service Responder

PEP Out PEP In

Stack

RR

RR

(optional)

Service Requester


Multi-tier Web Service Call

Front End Service

Web Application

WebGUI

R

Service Requester

Web Service

Service Application

ServiceResponder

ServiceRequester

R

R

R

R

Data Service

ServiceResponder

R

Web Service

Datastorage


Details of Authorization

Infrastructure

MasterPolicy Decision Point

OrganizationPDP

TrustPDP

UserPDP

PolicyStore

PolicyStore

TrustStore

Policy Decision Point Stack

Policy InformationPoint

Credential validationservice

Policy EnforcementPoint

Trust NetworkPDP

PolicyStore

Authorization

R

Discovery

Payload

InfrastructureR

Dashboard

R

R

R R

R


Legacy Integration

Service Responder

TAS3SOAP

Stack

Master PDP

XACML (in SOAP envelope)

Data ServiceWeb Service (e.g. Attribute Authority)

User

FE

AIPEP-In(accept req)

AIPEP-Out(filter)

AIPEPApplicationDependentPEP

LegacyData Source

Data

A

B

C

WP8SOA Gateway

WP8SOA GW

WP8database

WP8database

Figure 1: Application Integration using ADPEP and (A) WP8 SOA Gateway, (B) WP8 as frontend to WP8 SOA GW, (C) WP8 database.


Service Responder

TAS3SOAP

Stack

Master PDP



User

FE

AIPEP-In(accept req)

AIPEP-Out(filter)

AIPEP

Application

ADPEP

Figure 2: Application Integration: ADPEP implemented in application itself.


Service Responder

TAS3SOAP

Stack

Master PDP



User

FE

PEP-In(accept req)

PEP-Out(filter)

Application with PEP built in

Figure 3: Application Integration: PEP implemented directly in application.


Steps of a Web Service Call


Core Security Architecture Flows

Front End service A

IDP_1

Web GUI

PDP

1

23

SSO

123AA

Web Application

Authentication

PID E(123)A

Service Requestor

PEP


Front End service A

IDP_1

Identity Mapper IM

Service Provider B

Web GUI

PDP

PII

1

23

6

SSO

123AA

E(789)IMuse only: A

8 times

IM

E(789)IMuse only: A

8 times

IM

PDP

Web Application

Authentication

PID E(123)APID E(789)IM

Service Requestor

PEP

Service Responder

PEP

4

789 -> E(456)BE(456)B

B

E(789)IMuse only: B

8 times

IM

5

E(456)BB

E(789)IMuse only: B

8 times

IM

Service Responder

PEP

7


Front End service A

IDP_1

Identity Mapper IMPII Service B

Web GUI

PDP

PII

1

23

6

SSO

123AA

E(789)IMuse only: A

8 times

IM

E(789)IMuse only: A

8 times

IM

PDP

Web Application

Authentication

PID E(123)APID E(789)IM

Service Requestor

PEP

Service Responder

PEP4

789 -> E(456)B789 -> E(fgh)C

E(456)BB

E(789)IMuse only: B

8 times

IM

5E(456)B

B

E(789)IMuse only: B

8 times

IM

Service Responder

PEP

11

Service Requestor

E(789)IMuse only: B

8 times

IM

E(789)IMuse only: C

2 times

IM

E(fgh)CC

Role Authority C

Service Responder

PEP

78

E(789)IMuse only: C

2 times

IM

E(fgh)CC

fgh -> TAS3

9

10


Acronym ExpansionTG Trust Guarantor, the organization that operates TN ("Summit")

TN Trust Network

IdP Identity Provider (SAML role, aka authentication authority)

SP Service Provider: a member organization of TN that operatesFrontend and/or Web Services

Disco Service discovery, sometimes specifically identity enabledservice discovery such as Liberty ID-WSF Discovery Service.

DBDashboard, a web GUI for viewing audit records, work flow sta-tus, and/or viewing and editing privacy settings and permissions.

FE Frontend, here means web site, i.e. SP

WSWeb Service, SOAP based machine to machine communication.Sometimes specifically Identity enabled web service, e.g. LibertyID-WSF based WS.


TAS3 CoT Model

...Model Model

TAS3 CoT Audit


Modelling Modelling

Org BOrg A

Summit

Core

(Context A) (Context B)

IdP

Disco

IdP

Disco

FE FE

WS WS

SSO sub CoT B

SSO sub CoT A

WS layer

DB


Modelling andConfigurationManagement Domain

Runtime andEnforcementDomain


ModellingTool


Frontend Services

Backend WS

Dashboard

IdP

Disco* *

===

= =Trust Network level model

Connectors

= Routing &

aggregation

= PEP

*=

WS1WS2

PDP Trust

MasterPDP

Policy Store Trust Store

*

= =

CallPIP


Modelling andConfigurationManagement Domain

Runtime andEnforcementDomain


ModellingTool


Frontend Services

Backend WS

Dashboard

IdP

Disco* *

===

= =Trust Network level model

Connectors

= Routing &

aggregation

= PEP

*=

WS1WS2

PDP Trust

MasterPDP

Policy Store Trust Store

*

= =

CallPIP

Discoveractual usage

Feedbackforbehavioraltrust


Client App Service

Corp C Firewallor Packet Filter

Corp D Firewallor Packet Filter

Alice

Bob

1 2

34

Built-in rules of the application

Rules of the operator

Rules of the TN

Personal rules

Built-in rules of the service

Rules of the operator

Personal rules

TN PDP

Org C PDP Org D PDP

Alice PDP Bob PDP

PEPRq In

PEPRq Out

PEPRs In

PEPRs Out

MasterPDP Trust PDP

MasterPDP


tas3 architecture - zxidzxid.org/tas3/sampo-tas3-arch-servicewave-stockholm-slides-2009.pdf ·...

Documents