mr. abdelkrim boujraf, unisys mr. andreas schaad, sap research
DESCRIPTION
R4eGov Inter-Agency Collaboration – Security Performance Measurement. Mr. Abdelkrim Boujraf, Unisys Mr. Andreas Schaad, SAP Research Mr. Mohammad Ashiqur Rahaman, SAP Research funded by EU Integrated Project R4eGov. AGENDA. R4eGov Inter-agency collaboration. WS Performance Criteria. - PowerPoint PPT PresentationTRANSCRIPT
Mr. Abdelkrim Boujraf, Unisys
Mr. Andreas Schaad, SAP Research
Mr. Mohammad Ashiqur Rahaman, SAP Researchfunded by EU Integrated Project R4eGov
R4eGov Inter-Agency Collaboration
– Security Performance
Measurement
Evaluating WS * vs. SOAP Accounts
R4eGov Inter-agency collaboration
WS Performance Criteria
AGENDA
Evaluation Results
The problem….
The majority of eGovernment systems is and may have to remain heterogeneous.
Their configuration and definition of processes is likely to remain under local administration.
eGovernment interoperability in the EU follows an ad hoc approach and systems are only made interoperable when there is a shared purpose and some general legal guidelines.
We believe the majority of systems to require the methodologies, systems and tools for achieving the maturity level of collaborative organisations.
* Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.
EU Interagency Collaboration - The reality….
During a routine check Spanish customs intercept a shipment of coffee containing cocaine in the harbour of Malaga. The container came from Caracas, Venezuela and was supposed to be transported by road to Antwerp and to be delivered to a trade company called BE. A number of persons are taken into custody, whilst investigations start….. The involved authorities (Europol and Eurojust)*
need to collaborate in a quick and efficient manner.– European Arrest Warrant– Rogatory Letter– Joint Investigation Teams– ….
They need to remain in control of their systems They need to follow local as well as EU-wide laws
and agreements
* Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.
Requirements
Local case management
Exchange of documents
Access Control on documents
Traceability
Chain of evidence
European and Local Directives on Data Usage
Collaboration agreements
Can in parts be addressed by using OASIS WS* standards.
General WS Security Setup
WS-Policydescribes the capabilities and constraints on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms)
WS-SecureConversationdescribes how to manage and authenticate a series of message exchanges
Requester Web Service
Security Token
Service
Policy
Security Token Claims
Policy
Policy
Security TokenClaims
Security Token
Claims
WS-Securityattaching signature and encryption headers / security tokens to SOAP messages e.g. X.509 certificates and Kerberos tickets, to messages
WS-Trustdescribes a framework for trust models that enables Web services to trust other domains
Performance / A general Web Service invocation flow Some Performance Relevant Criteria (incomplete)
– Methods for issuing, renewing, and validating security tokens;– Establishing security contexts for a conversation of messages.– Amending, Renewing, and cancelling the security contexts.– Computing and passing derived keys and session keys.– Verify Subjects / Security Attributes
Approach to Performance Measurement
Our Problem: What can we measure performance against? No real benchmarks for WS* Performance Measurement.
Our Approach: Build our own solution for defined purpose scope Measure WS* key performance indicators against this
Our (simplified) requirements: Preservation of message confidentiality / integrity Handling of complex / large messages Focus on prevention of XML re-writing attacks
Our Proposal: SOAP Account: Keeps record of SOAP message structure / elements. Requires small component to be deployed on each SOAP processing
node.
SOAP Account: Message flow in the proposed technique
A SOAP request using a SOAP Account
<Envelope>…… <Header> <Security> <BinarySecurityToken Id=" Id-2" ValueType="...X509v3"> MIIEZzCCA9CgAwIBAgIQEmtJZc0...</BinarySecurityToken> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="..xml-exc-c14n#"/> <SignatureMethod Algorithm="...#rsa-sha1"/> <Reference URI="#Id-1"> <DigestMethod Algorithm="...#sha1"/> <DigestValue>d5AOd..=</DigestValue> </Reference> <Reference URI="#Id-2>...</Reference>
<Reference URI="#Id-3>....</Reference> </SignedInfo> <SignatureValue>e4EyW...=</SignatureValue> <KeyInfo><SecurityTokenReference><Reference URI="#Id-2" ValueType="...#X509v3" /></KeyInfo>
RST token is signed
Receiver can verify
<SoapAccount Id=”#Id-3”> <NoChildOfEnvelope>2</> <NoOfHeader>2</> </SoapAccount>
<Body Id="Id-1"> <RequestSecurityToken> <TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct </TokenType><RequestType>http://schemas.xmlsoap.org/ ws/2004/04/security/trust/Issue </RequestType> <Base>...</Base> </RequestSecurityToken></Body>
SOAP Account added
Simulated SOAP, WS Policy, SOAP Account
<Envelope> …… <Header> <Security> <BinarySecurityToken Id=" Id-2" ..> ...</BinarySecurityToken> <Signature> <SignedInfo> …… <Reference URI="#Id-1"> …..</Reference> <Reference URI="#Id-2”> ....</Reference> </SignedInfo> <SignatureValue>e4EyW...= </SignatureValue> <KeyInfo>…</KeyInfo> <Body Id="Id-1"> <RequestSecurityToken> <TokenType>http://schemas.xmlsoap .org/ws/2005/02/sc/sct </TokenType> <RequestType>http://schemas.xml soap.org/ ws/2004/04/security /trust/Issue </RequestType.. </RequestSecurityToken>
<wsp:Policy …..> …..
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
</wsp:Policy>
SOAP
WS Policy
<SoapAccount Id=”#Id-3”>
<NoOfHeader>2</>
</SoapAccount>
SOAP Account
2695 bytes to 51551 bytes 388 bytes
197 bytes
Performance Criteria
Requestor Soap Size VS Policy and SoapAccount size Comparison
0
10000
20000
30000
40000
50000
60000
Size
in Bytes
Request Soap With Soap Account SenderPolicy File Size SenderSoap AccountSize
Request SOAP size vs. requestor Soap Account header size and Policy file size.
SOAP Account size vs. Policy file size.
Relative comparison of signature processing in both ends.
Enforcement time of SOAP Account and Policy in sender (requestor).
Enforcement time of SOAP Account and Policy in the receiver.
XML rewriting attack detection time using SOAP Account and Policy.
Results/ChartComparison Criteria
xmlRewriting Attack Detection Time Comparison
0
5
10
15
20
25
30
35
Received Soap size With Soap Account(Bytes)
xmlRewritngAttackDetectionTimeUsing Policy xmlRewitingAttackDetectionTimeUsingSoapAccount
SOAP Size 2695 to 51551 bytes
SOAP Account 197 bytes ~0.72% of SOAP
Policy File 388 bytes ~1.42% of SOAP
Scalability.
~15% more time in the Requestor
Comparable enforcement time for both in the Requestor.
~1.50 % faster XML Rewriting Attack Detection using SOAP Account.SOAP Account is scalable.
~30% less Enforcement time using SOAP Account in the Receiver.
SOAP size > 4500 bytes..SOAP Account Enforcement Time ~ Policy Enforcement Time.
1. SOAP Account Processing. 2. Policy processing.3. Signature Processing. 4. Attacker Simulation
Summary & Conclusion
We presented a „real-world“ collaboration scenario and security requirements
WS* can be deployed to satisfy some of these requirements
WS* Security performance indicators
Measure these indicators against our own SOAP account solution
In summary, our solution is more performant due to being purpose-built for avoiding XML rewriting attacks (overly simplified).
Not really „scientific“ approach but valuable lessons learnt on: Establishing a set of Security / Web Service Performance Indicators Implementation and Setup, Memory Consumption, Processing, Key Generation,
Validation, Message Sizing etc.
Current research work is focusing on XACML testing
Overall goal is a general test tool suite for standards evaluation
Thank You & Questions
[email protected]@sap.com
* Europol and Eurojust are SAP EU project partners but not SAP or Unisys customers. The case study is for illustration / requirements engineering purposes only.