An Analysis of Trust Requirements and Design Choices for Trust Management in Web Services Based Service Oriented Architectures Bienvenida Pagdanganan Supervisor:

An Analysis of Trust Requirements and Design Choices for Trust Management in Web Services

Based Service Oriented Architectures

Bienvenida PagdangananBienvenida Pagdanganan

Supervisor: Prof Vijay Varadharajan

04/21/23 1Bienvenida Pagdanganan

Main Problem

22

With Web Services:

• Who the requestors are• Who the providers are• What credential is being requested• What specific services are being requested

• Who is trustable• Who is not• How are they trusted

04/21/23 Bienvenida Pagdanganan

Main Problem

33

BPAY Scenario:

Alice pays electricity bill through BPAYAlice logs in to her Internet Banking system

using Username AND PasswordAlice enters her electricity account number and other identity information Alice’s bank and electricity provider has some agreement that facilitates the serviceAlice trusts that the service has been completed in her behalf by the bank


Main Problem

44

Authentication in Web services:• Mechanism by which clients and service providers prove to one another that they are acting on behalf of specific users or systems• Client usually presents identifier • Service provider verifies client’s claimed identity


Authorization • Allow only authenticated service identities to access resources, such as hosts, files, Web pages, components, and database entries, to name a few

Aim

55

To address the trust requirements needed to use or provide a Web service through studies about

trust model and languagetrust policy languagetrust management systemsfederation and trust

in relation to trust management


Significant Achievements

66

This study provides the following:• A framework for a hybrid trust model incorporating hard trust and soft trust, and the attributes in hard trust and soft trust• A methodology by example for evaluating reputation-based soft trust attribute• A methodology by example for incorporating soft trust attributes in a service policy• A federation and trust scenario in Web services incorporating soft trust body, Reputation Authority, and soft trust attributes


Roadmap to achievements: Project Scope

Studies on Web Services Trust Model Trust Policy for Web Services Trust Management in Web Services Based SOA Federation and Trust in Web Services


What is....

Web service self- contained software module available via a network, such as the Internet completes tasks, solves problems, or conducts transactions service on behalf of a user or application

Service Oriented Architecture a logical way of designing a software system provide services either to end-user applications or to other

services distributed in a network use published and discoverable interfaces


Roadmap – Web Services Trust Model

Studies on Hoffman, Lawson-Jenkins et al. 2006 Lin and Varadharajan 2007 Web Services Security Plan and Roadmap (2002) WS-Trust



Hoffman, Lawson-Jenkins et al. 2006 Develop improved trust model and related metrics for

distributed computer-based systems Incorporate security, privacy, safety, usability, reliability, and

availability factors into trust vector Incorporate factors such as verification techniques, user

knowledge, user experience, and trust propagation in their model

Define ‘expectation’ - experience with an application or service, and the reputation of the vendor providing the service or product

(we discuss as soft trust attributes) Consider metrics (we discuss as trust attributes)



Lin and Varadharajan 2007 Propose a hybrid trust model for enhancing security in

distributed systems by combining hard and soft trust relationships and associated operations

Consider soft trust decision making, based on behaviour and evidence and the specified thresholds for these opinion-based soft trust requirements

Our paper similarly discusses hard and soft trust attributes and trust relationships, we consider Web services rather than mobile agent system



IBM and Microsoft 2002 - End to End Security Web Service – require incoming message

prove a set of claims (referred to as policy)

Requester – send messages with proof of required claims (security tokens) with the messages.

Messages demand specific action Messages prove their sender has

claim to demand the action Requester can obtain claim through the

Security Token Services (STS broker trust by issuing security tokens)


Figure 1 Security token service model(IBM and Microsoft 2002)


WS- Trust TRUST – represented through exchange and

brokering of security tokens Specifications to enable application to construct

trusted SOAP message exchange Web Services trust specification for

Requesting and obtaining security tokens Managing trusts and establishing relationships Establishing and assessing trust relationships



WS- Trust : managing trusts and establishing and assessing trust relationships

Verify that claims in token are sufficient to comply with policy and that message conforms to policy

Verify that attributes of claimant are proven by signatures, claims are either proven or not based on policy

Verify that issuers of security tokens (including all related and issuing security token) are trusted to issue claims they have made



WS-Trust - Trust relationships can be: Direct trust - relying party accepts as true all (or some

subset of) the claims in token sent by the requestor

Requester Web service Brokered trust, a trust proxy (second party) – read policy

information and request appropriate security tokens from an issuer of security tokens, thus vouching for a third party

Security Token Service

Requester Web service


Roadmap – Trust Policy for Web Services

Studies on Vuong, Smith et al. 2001 Nagarajan, Varadharajan et al. 2007 WS-Policy



Vuong, Smith et al. 2001 Discuss practical concepts employed in enterprise

environment for managing security policies Use eXtensible Markup Language (XML) Design specification for security policy use structured

language model (XML), separate semantics API, and standardized policy schema model to represent and implement security policies.

We consider their methodology in our study to develop a methodology by example for incorporating soft trust attributes in a service policy



Nagarajan, Varadharajan et al. 2007 Propose a 3-level granularity model with levels, high, mid and

low properties for authorization credentials for trusted platform

Present methodology for capturing requirements through compositions and Component Property Certificate

We adapt their methodology as a way in establishing our work to develop a methodology by example for evaluating reputation-based soft trust attributes




(01) <wsp:Policy

xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

>(02) <wsp:ExactlyOne>(03) <sp:Basic256Rsa15 />(04) <sp:TripleDesRsa15 />(05) </wsp:ExactlyOne>(06) </wsp:Policy>

An example of a security policy

WS-Policy • An XML Infoset called a policy expression that contains domain-specific, Web Service policy information• Core set of constructs to indicate how choices and/or combinations of

domain specific policy assertions apply in Web services environment

Roadmap – Trust Management in Web Services Based SOA

Studies on: The PolicyMaker Trust Management System (Blaze,

Feigenbaum et al. 1996) REFEREE: Trust Management for Web Applications (Chu,

Feigenbaum et al. 1997) The KeyNote Trust Management System(Blaze, Feigenbaum et

al. 1999)

Then…….Our ApproachIncorporating Hybrid Trust Attributes in Policy



The PolicyMaker Trust Management System (Blaze, Feigenbaum et al. 1996)

Interface that separates generic mechanisms from application-specific policy

Return simple yes/no answer or additional restrictions that would make the proposed action acceptable

Our interest is language structure Way policy is written through queries of the form:

key1,key2,...keyn Requests ActionString Source ASSERTS AuthorityStruct WHERE Filter



REFEREE: Trust Management for Web Applications (Chu, Feigenbaum et al. 1997)

Rule-controlled Environment for Evaluation of Rules, and Everything Else

Provides both general policy-evaluation mechanism and language for specifying policies

Return value when asking for authorization Yes, the action may be taken because sufficient credentials exist

for the action to be approved” “No, the action may not be taken because sufficient credentials

exist to deny the action” “The trust management system was unable to find sufficient

credentials to approve or to deny the requested action”



The KeyNote Trust Management System(Blaze, Feigenbaum et al. 1999)

Language describing policy and credential assertion, structures of action descriptions and model of computation

Evaluates policy through a policy compliance value (PCV) PCV advises application how to process the requested action. In simplest case, the compliance value is Boolean (e.g., reject

or approve)



The KeyNote Trust Management System(Blaze, Feigenbaum et al. 1999)

Conditions:@user_id == 0 -> “full_access”; # clause (1)@user_id < 1000 -> “user_access”; #clause (2)@user_id < 10000 -> “guest_access”; #clause (3)user_name == “root” -> “full_access”; #clause (4)

Given “user_id” is “1073” and the “user_name” attribute is “root”,

possible compliance value set would contain the following: “guest_access” (by clause (3)) and “full_access” (by clause (4))



Our Approach A framework for

trust management A hybrid trust

model for managing trust incorporating hard trust and soft trust


Our Approach – Trust Management in Web Services Based SOA

Hybrid Trust Composition

Trust relationships based on exchange and brokering of hard trust attributes and on support of soft trust attributes established by corresponding security authorities


Table 1. HYBRID TRUST MODEL POLICY-BASED or HARD TRUST

Claims Security Token Policy

REPUTATION-BASED or SOFT TRUST Reputation Reference Membership Experiences Community Feedback Etc.

Our Approach –

Trust Management in Web Services Based SOA

Hard Trust Composition

“strong security” mechanisms

Result is a binary decision- trusted or not


Table 2. Hard Trust – Claim Attributes User Name and Password Secret Keys Digital Signatures Digital Certificates Certificates from Trusted Certification Authorities Proof of Possession


Soft Trust Composition

“soft computational” approach, a method of evaluation of soft trust attributes

developed by illustration through a hypothetical example


Table 3. REPUTATION-BASED or SOFT TRUST ATTRIBUTES Reputation Reference Membership Experiences Community Feedback Audit Trails Record of Usage of Services

Acceptance/Rejection of Services

04/21/23 Bienvenida Pagdanganan 29

Hypothetical Example:A Web service provided by ABC company for purchasing shares of stocks - Must be citizens of its country only - May have loyalty cards with the company- Have transactions above a threshold amount $D - Have reference from company staff

Company Assertions:Is_Citizen = ‘Y’ #clause (1)has_LoyaltyCard = ‘Y’ #clause (2)has_No_LoyaltyCard = ‘Y’ #clause (3)has_Transaction_Threshold > $D = ‘Y’ #clause (4)has_Reference_From_Staff = ‘Y’ #clause (5)



Hypothetical Example cont.:Company has set to true (‘Y’) only the following compositionOrder of assertion: ascending, highest to lowestAll other combinations are not acceptable.

(1) {“Is_Citizen”, “has_LoyaltyCard”, “has_Transaction_Threshold > $D”, “has_Reference_From_Staff”}, (2) {“Is_Citizen”, “has_LoyaltyCard”, “has_Transaction_Threshold > $D”}, (3) {“Is_Citizen”, “has_LoyaltyCard”, “has_Reference_From_Staff ”}, (4) {“Is_Citizen”, “has_No_LoyaltyCard”, “has_Transaction_Threshold > $D”}, (5) {“Is_Citizen”, “has_No_LoyaltyCard”, “has_Reference_From_Staff ”}



Hypothetical Example cont.:

Evaluation of assertions• A decision response (Y or N) for reputation will be delivered for

compositions (1) through (5). • Each composition has weight value corresponding to reputation of

requestor of Web service• Notation use to indicate weight value where weight value is a function of composition; R1 = W(C1) = Extremely high reputation

R2 = W(C2) = Strongly high reputation R3 = W(C3) = Very high reputation R4 = W(C4) = Moderately high reputation R5 = W(C5) = High reputation

• Reputation weight value is referred to as ‘Reputation Token’




Reputation Authority • Soft trust authority body• The Reputation Authority can then validate the Reputation Rating of the user for a given role or capability as Identity based attributes for the user.


Inco

rpora

ting H

ybri

d T

rust

A

ttri

bute

s in

Polic

yOur Approach – Trust Management in Web Services Based SOA

(01) <wsp:Policy wsu:Id=”tokens”xmlns:wsse="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" >

(02) <wsp:ExactlyOne wsp:Usage=’Required”>(03) <wsp:All>(04) <wsse:SecurityToken />(05) <wsse:TokenType> wsse:ReputationToken </wsse:TokenType>(06) </wsee:SecurityToken>(07) <wsse:SecurityToken />(08) <wsse:TokenType> wsse:LoyaltyCardNumber </wsse:TokenType>(09) </wsee:SecurityToken>(10) <wsse:SecurityToken />(11) <wsse:TokenType> wsse:UsernameToken </wsse:TokenType>(12) </wsee:SecurityToken>(13) </wsp:All> (14) <wsp:All>(15) <wsse:SecurityToken />(16) <wsse:TokenType> wsse:ReputationToken </wsse:TokenType>(17) </wsee:SecurityToken>(18) <wsse:SecurityToken />(19) <wsse:TokenType> </wsse:TokenType>(20) </wsee:SecurityToken>(21) <wsse:SecurityToken />(22) <wsse:TokenType> wsse:UsernameToken </wsse:TokenType>(23) </wsee:SecurityToken>(24) </wsp:All> (25) </wsp:ExactlyOne>(26) </wsp:Policy>


Mech

an

ism

to f

edera

te a

cross

tr

ust

ed a

uth

ori

ties

inco

rpora

ting

Reputa

tion

Auth

ori

ties

Our Approach –Federation and Trust in Web Service

Figure 11 Simple federation scenario incorporating Reputation Authorities

Identity Provider/Reputation Authorities

Identity provider/Security Token Service/Reputation Authorities

Requestor Web service with resources

1. Obtain identity security and reputation token

Trust

2. Present/prove identiy/reputation

3. Obtain access token

4. Present/prove access in messages


1. ABC Company issued Alice a Kerberos security token and a reputation token. 2. Currency service’s policy only accepts security and reputation tokens issued by its own security token service and reputation authority. 3. We assume the administrators at ABC Company and Business456 have exchanged public key certificates and reputation tokens in order to federate security. 4. We further assume that Alice only supports symmetric key technology. 5. Based on the Currency Web service policy, Alice needs to acquire a security token and a reputation token that can be used to access the security token service and the reputation authority at Business456. 6. Alice first contacts her security token service and reputation authority that is intended for the Business456 security token service and reputation authority. 7. Using the security and reputation token intended for the Business456 security token service and reputation authority, Alice requests security and reputation token for the Currency service. 8. The Business456 security token service provides Alice security token for the Currency service, and reputation token required by the Currency service policy. 9. Using the security and reputation token intended for the Currency service and the associated symmetric key, Alice makes the requests to the Currency service.

Our Approach –Federation and Trust in Web Service

ABC CompanySecurity Token Service

Alice

ABC CompanyReputation Authority

Currency Service

Business456Security Token Service

Business456Reputation Authority


Future Work

Suggested Work:

Development of a trust management system incorporating reputation-based token in its language for policy formulation

Study to consider the formal institution of Reputation Authority

In our approach to evaluate reputation using weighted values, further work may adapt such methodology and compare and contrast with some existing models

Concept of quality trust can be further studied

Documents

An Analysis of Trust Requirements and Design Choices for Trust Management in Web Services Based Service Oriented Architectures Bienvenida Pagdanganan Supervisor: