WSO2 as a Crypto Services Pla4orm By Roger CARHUATOCTO | @Chilcano
1. Abstract As Internet transacBons increase in value, the opportunity to intercept, hijack, and maliciously modify messages grows. While the OASIS Digital Signature Service Standard has existed for ﬁve years, protecBng transacBons using the standard is oNen diﬃcult. A Cryptographic Services Pla4orm delivers a service set assuring integrity, authenBcity and conﬁdenBality of transacBons over the Internet. In this session, I will present a the construcBon of a cryptographic services pla4orm using WSO2 middleware, and how the pla4orm delivers security mediaBon between a Liferay Portal and a CerBﬁcaBon Authority or Crypto Service Provider.
2. Overview (1/2) • The trend is to bring applicaBons to more open and centralized environments. • The business logic transcends physical boundaries of the organizaBon and oNen have interfaces to interact with external systems. • With so much diversity of interacBons, clients, servers, and heterogeneous systems must ensure trust and security at all points of interacBon and transacBon.
2. Overview (2/2) • For these reasons is required end-‐to-‐end security. From the client to the server covering all unsafe areas. Security Context Security Context Client Canal of Business Web Service Requester CommunicaBon ApplicaBons
3. The requeriments (1/2) • Assure trust and security across of criBcal business processes. • End-‐to-‐end Security 1.-‐ Fundamental Principles (ConﬁdenBality, Integrity, Availability) 2.-‐ AuthenBcaBon Requeriments Security 3.-‐ AuthorizaBon Principles 4.-‐ Accountability 5.-‐ Non RepudiaBon
3. The requeriments (2/2) • What kind of App require security? • E-‐Invoice, DigiBzaBon CerBﬁed, Secure NoBﬁcaBon, Long Term Data Archiving, e-‐DNI, e-‐Payment, *any*… Security Context Security Context Client Canal of Business Web Service Requester CommunicaBon ApplicaBons Security Context Client Canal of Business Web Service Requester CommunicaBon ApplicaBons Trusted Third Party
3.1. CIA: ConﬁdenBality • ConﬁdenBality is the term used to prevent the disclosure of informaBon to unauthorized individuals or systems. Example: • A credit card transacBon on the Internet requires the credit card number to be transmiced from the buyer to the merchant and from the merchant to a transacBon processing network. • The system acempts to enforce conﬁdenBality by encrypBng the card number during transmission, by limiBng the places where it might appear (in databases, log ﬁles, backups, printed receipts, and so on), and by restricBng access to the places where it is stored. • If an unauthorized party obtains the card number in any way, a breach of conﬁdenBality has occurred. • ConﬁdenBality is necessary (but not suﬃcient) for maintaining the privacy of the people whose personal informaBon a system holds.
3.2. CIA: Integrity • In informaBon security, integrity means that data cannot be modiﬁed undetectably. • This is not the same thing as referenBal integrity in databases, although it can be viewed as a special case of Consistency as understood in the classic ACID model of transacBon processing. • Integrity is violated when a message is acBvely modiﬁed in transit. InformaBon security systems typically provide message integrity in addiBon to data conﬁdenBality.
3.3. CIA: Availability For any informaBon system to serve its purpose, the informaBon must be available when it is needed. This means that the compuBng systems used to store and process the informaBon, the security controls used to protect it, and the communicaBon channels used to access it must be funcBoning correctly. High availability systems aim to remain available at all Bmes, prevenBng service disrupBons due to power outages, hardware failures, and system upgrades. Ensuring availability also involves prevenBng denial-‐of-‐service acacks.
3.4. AuthenBcaBon AuthenBcaBon is the establishment and veriﬁcaBon of user idenBty. AuthenBcaBon (from Greek: αὐθεντικός; real or genuine, from αὐθέντης authentes; author) is the act of conﬁrming the truth of an acribute of a datum or enBty. This might involve conﬁrming the idenBty of a person or soNware program, tracing the origins of an arBfact, or ensuring that a product is what its packaging and labeling claims to be. AuthenBcaBon oNen involves verifying the validity of at least one form of idenBﬁcaBon.
3.5. AuthorizaBon AuthorizaBon is the granBng of permission to access speciﬁc informaBon and carry out speciﬁc acBons AuthorizaBon (also spelt AuthorisaBon) is the funcBon of specifying access rights to resources, which is related to informaBon security and computer security in general and to access control in parBcular. More formally, "to authorize" is to deﬁne access policy. For example, human resources staﬀ are normally authorized to access employee records, and this policy is usually formalized as access control rules in a computer system. During operaBon, the system uses the access control rules to decide whether access requests from (authenBcated) consumers shall be approved (granted) or disapproved (rejected). Resources include individual ﬁles or items data, computer programs, computer devices and funcBonality provided by computer applicaBons. Examples of consumers are computer users, computer programs and other devices on the computer.
3.6. Accountability • Accountability is the ability to Be acBons to users • Accountability is important for audiBng purposes (provides traceability, can be used to show compliance with regulaBons or standards) • Non-‐repudiaBon is a special case of accountability: • Ensures a party to a transacBon cannot deny its authenBcity • Primary purpose is to prevent a user from denying responsibility for a speciﬁc acBon • Establishing non-‐repudiaBon requires a high level of trust in the authenBcaBon credenBals • Security purists argue that suﬃcient trust for non-‐repudiaBon cannot be established without external cerBﬁcaBon of idenBty
3.7. Non RepudiaBon In law, non-‐repudiaBon implies ones intenBon to fulﬁll their obligaBons to a contract. It also implies that one party of a transacBon cannot deny having received a transacBon nor can the other party deny having sent a transacBon. Electronic commerce uses technology such as digital signatures and public key encrypBon to establish authenBcity and non-‐repudiaBon.
4. OrganizaBons for XML Standards WS-‐* World Wide Web XML Consor-um Internet Engineering PKIX Task Force
5. XML Security Standards overview 1 4 7 SAML (Security XML-‐DSIG (XML Digital DSS (Digital Signature AsserBon Markup Signature) Services) Language) 2 5 8 XACML (eXtensible XAdES (XML Advanced PKIX (Public-‐Key Access Control Markup Electronic Signatures) Infrastructure -‐ X.509) Language) 3 6 WS-‐Security XML-‐ENC (XML It is not XML, but EncrypBon) who does not use it?
5.1. XML Security Standards overview XML-‐based framework for How is used: SAML (Security communicaBng user authenBcaBon, enBtlement, • Web Single Sign-‐On AsserBon Markup and acribute informaBon. As its name suggests, SAML allows business enBBes to make asserBons • Acribute-‐Based AuthorizaBon • Securing Web Services Language) regarding the idenBty, acributes, and enBtlements of a subject (an enBty that is oNen a human user) • Federated idenBty to other enBBes, such as a partner company or Other standards related: another enterprise applicaBon. • Liberty Alliance: IdenBty FederaBon Framework hcp://www.oasis-‐open.org/commicees/ (ID-‐FF). security • Shibboleth • XACML • WS-‐Security
5.2. XML Security Standards overview The standard deﬁnes a declaraBve access control How is used: XACML (eXtensible policy language, a request/response language • XACML is primarily an Acribute Based Access Access Control Markup implemented in XML for describing how to evaluate authorizaBon requests according to the Control system (ABAC). • Role-‐based access control (RBAC) can also be Language) rules deﬁned in policies. The policy language is used to express access implemented in XACML as a specializaBon of ABAC. control policies ("who can do what when"). hcp://www.oasis-‐open.org/commicees/ Other standards related: xacml • SAML
5.3. XML Security Standards overview The protocol speciﬁes how integrity and How is used: WS-‐Security conﬁdenBality can be enforced on messages and • End-‐to-‐end security allows the communicaBon of various security • Non-‐RepudiaBon token formats, such as SAML, Kerberos, and X.509. • AlternaBve transport bindings (i.e. JMS, SMTP) • Reverse proxy/common security token Its main focus is the use of XML Signature and XML EncrypBon to provide end-‐to-‐end security. Other standards related: • XML-‐DSig hcp://www.oasis-‐open.org/commicees/ • XML-‐Enc wss • WS-‐SecureConversaBon
5.4. XML Security Standards overview • Speciﬁes a process for digitally signing data and How is used: XML-‐DSIG (XML Digital represenBng the result in XML • Can be used to sign data (a resource) of any Signature) • Deﬁne the processing rules and syntax for XML digital signatures. type, typically XML documents, but anything that is accessible via a URL can be signed. • A serialised form in XML is deﬁned for the signature • The signatures can be applied to informaBon in Other standards related: any form, not just XML-‐formaced informaBon • PKCS#7 hcp://www.w3.org/Signature/ • SOAP • SAML • XML-‐Enc
5.5. XML Security Standards overview Is a set of extensions to XML-‐DSig How is used: XAdES (XML Advanced recommendaBon making it suitable for advanced • E-‐Invoicing Electronic Signatures) electronic signature. While XML-‐DSig is a general framework for • Secure Archiving • Secure DigiBzaBon digitally signing documents, XAdES speciﬁes • Etc. precise proﬁles of XML-‐DSig for use with advanced electronic signature in the meaning of European Other standards related: Union DirecBve 1999/93/EC. One important • XML-‐Dsig hcp://www.w3.org/TR/XAdES/ beneﬁt from XAdES is that electronically signed • CAdES (CMS Advanced Electronic Signature) documents can remain valid for long periods, even • PAdES (PDF Advanced Electronic Signature) if underlying cryptographic algorithms are broken. • Trusted Bmestamping XAdES deﬁnes six proﬁles (forms) diﬀering in protecBon level oﬀered. Each proﬁle includes and extends the previous one: • XAdES, basic form just saBsfying DirecBve legal requirements for advanced signature; • XAdES-‐T (Bmestamp), adding Bmestamp ﬁeld to protect against repudiaBon; • XAdES-‐C (complete), adding references to veriﬁcaBon data (cerBﬁcates and revocaBon lists) to the signed documents to allow oﬀ-‐line veriﬁcaBon and veriﬁcaBon in future (but does not store the actual data); • XAdES-‐X (extended), adding Bmestamps on the references introduced by XAdES-‐C to protect against possible compromise of cerBﬁcates in chain in future; • XAdES-‐X-‐L (extended long-‐term), adding actual cerBﬁcates and revocaBon lists to the signed document to allow veriﬁcaBon in future even if their original source is not available; • XAdES-‐A (archival), adding possibility for periodical Bmestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during long-‐Bme storage period.
5.6. XML Security Standards overview • Speciﬁes a process for encrypBng data and How is used: XML-‐ENC (XML represenBng the result in XML such that it is • Privacy EncrypBon) only discernable to the intended recipients and opaque to all others. • EncrypBon of informaBon • The informaBon that is encrypted can be arbitrary data (including an XML document), an XML element, or XML element content Other standards related: • The result is an XML EncrypBon element that • XML-‐DSig hcp://www.w3.org/EncrypBon/2001/ contains or idenBﬁes the cipher data. • TLS/SSL • PGP
5.7. XML Security Standards overview • Describes two XML-‐based request/response How is used: DSS (Digital Signature protocols (a signing protocol and a verifying • Trusted Third Party (ValidaBon Systems, Services) protocol). • Through these protocols a client can send Archiving, …) documents to a server and receive back a Other standards related: signature on the documents; or send • PKI documents and a signature to a server, and • PKIX receive back an answer on whether the hcps://www.oasis-‐open.org/commicees/ • WS-‐Security signature veriﬁes the documents. dss • XML-‐DSign, XML-‐Enc and XAdES. • The DSS Core speciﬁcaBons provide the basic protocols and elements which are adapted to support speciﬁc use cases in the DSS proﬁles. Document Signing Verifying
5.7. XML Security Standards overview DSS Core: • Provides the basic protocols and elements which are adapted to support speciﬁc use cases in the DSS proﬁles. DSS Proﬁles: 1. DSS Time-‐stamp proﬁle deﬁnes the use of the DSS Core protocols to support creaBon and veriﬁcaBon of Bme-‐stamps. The proﬁle includes support for the creaBon of XML Time-‐stamps as deﬁned in the Core and binary Bme-‐stamps as deﬁned in RFC 3161. 2. DSS Asynchronous proﬁle deﬁnes a simple mechanism for asynchronous DSS signing and veriﬁcaBon requests. 3. DSS Code-‐signing proﬁle deﬁnes the use of the DSS Core protocols to support the signing of a soNware program. 4. DSS J2ME Code-‐signing proﬁle deﬁnes the use of the DSS Core protocols to support the signing of a soNware program as speciﬁed in the Java 2 Micro EdiBon (J2ME), Mobile InformaBon Device Proﬁle 2.0. 5. DSS EnBty seal proﬁle deﬁnes the use of the DSS Core protocols to support creaBon and validaBon of a “seal” created by a given EnBty or OrganizaBon on electronic data. 6. DSS EPM proﬁle deﬁnes the use of the DSS Core protocols to support the Universal Postal Union’s Electronic PostMarking (also called Digital PostMark) service. 7. DSS German Signature Law proﬁle deﬁnes the use of the DSS Core protocols to support creaBon and validaBon of qualiﬁed signatures according to the guidelines given by the German signature law. 8. DSS AdES proﬁle deﬁnes the use of the DSS Core to support the creaBon and veriﬁcaBon of XML and binary Advanced Electronic Signatures as deﬁned in ETSI TS 101 733 and TS 101 903. 9. DSS Signature Gateway proﬁle deﬁnes the use of the DSS Core to support the transform of both signing technology and credenBal logisBcs.
5.8. XML Security Standards overview • A public-‐key infrastructure (PKI) is a set of How is used: PKIX (Public-‐Key hardware, soNware, people, policies, and • Create CA, RA, e-‐DNI, SSL, Digital Dignature of Infrastructure -‐ X.509) procedures needed to create, manage, distribute, use, store, and revoke digital documents, Sign SoNware, … cerBﬁcates which are used to verify that a Other standards related: parBcular public key belongs to a certain enBty. • RSA PKCS (Public Key Cryptography Standards) • The PKI creates digital cerBﬁcates which map public keys to enBBes, securely stores these hcps://en.wikipedia.org/wiki/PKCS cerBﬁcates in a central repository, and revokes hcps://datatracker.ie4.org/wg/pkix/ them if needed. • A PKI consists of: • A cerBﬁcate authority (CA) that both issues and veriﬁes the digital cerBﬁcates. • A registraBon authority which veriﬁes the idenBty of users requesBng informaBon from the CA. • A central directory. For example a secure locaBon in which to store and index keys. • A cerBﬁcate management system[clariﬁcaBon needed] • A **cerBﬁcate policy**
6. FOSS Crypto products 1. eID DSS • Belgium Federal ICT Department (FedICT) • hcps://code.google.com/p/eid-‐dss Supports the creaBon of XML signatures according to XAdES-‐X-‐L using a browser POST protocol to navigate the web browser from Relying Party to the eID DSS. ANer veriﬁcaBon of the to-‐be-‐signed XML document (the visualizaBon of the XML structure can be styled using XSLT) the ciBzen can sign the XML structure using the eID card via the eID Applet technology. ANer signature ﬁnalizaBon by the eID DSS (upgrade from XAdES-‐BES to XAdES-‐X-‐L using the eID Trust Service) the eID DSS will navigate the web browser back to the Relying Party where the work ﬂow can conBnue. For signature veriﬁcaBon the Relying Party can use an eID DSS web service according to the OASIS DSS speciﬁcaBons. The eID DSS signature validaBon web service is using the eID Trust Service for historical cerBﬁcate chain validaBon. Because both the signature creaBon and signature validaBon is outsourced to the eID DSS, the Relying Party does not need to have noBon of the actual used signature format. This way the Relying Party can fully focus on the business work ﬂow and deﬁne an XML schema according to its business needs.
6. FOSS Crypto products 2. Digital Signature Service • European Comission – Interoperability SoluBons for European Public AdministraBons (ISA) • hcp://joinup.ec.europa.eu/soNware/sd-‐dss/descripBon The DSS soNware allows Member States to create and verify X/CAdES forms up to the -‐A form and PAdES forms up to LTV originaBng from other MS when used with documents. In parBcular it: • supports the requirements in Commission Decision 2011/130/EU; • for veriﬁcaBon makes use of Member States trusted lists; • is available under the form of an SDK and as a standalone applicaBon. • allows easy use of the MOCCA adapter to increase the support of Ms smalrtcards at the signing aide
6. FOSS Crypto products 3. SignServer: • hcp://www.signserver.org • Is an applicaBon framework performing cryptographic operaBons for other applicaBons. • Its intended to be used in environments where keys are supposed to be protected in hardware but it isnt possible to connect such hardware to exisBng enterprise applicaBons or where the operaBons are considered extra sensiBve so the hardware have to protected more carefully. • Another usage is to provide a simpliﬁed method to provide signatures in diﬀerent applicaBon managed from one locaBon in the company. SignServer has ready to use modules for: • TimeStamp Authority (RFC 3161 compliant) • Signers for diﬀerent documents: PDF, XML, ODF, OOXML, MRTD (ePassport document signer) • General purpose signers: CMS • Validators for documents: XML • The modules can be used using HTTP or web services interfaces. SignServer also contains funcBons for: • CerBﬁcate ValidaBon Service Framework for validaBng cerBﬁcates using CRLs or OCSP • Diﬀerent kinds of tokens can be used to perform sign and crypto operaBons: SoN token using JKS or PKCS12 ﬁles, PKCS#11 HSM tokens, such as the UBmaco CryptoServer, SafeNet ProtectServer and Luna, nCipher nShield, etc.
6. FOSS Crypto products 4. EJBCA: • EJBCA is an enterprise class PKI CerBﬁcate Authority built on JEE technology. It is a robust, high performance, pla4orm independent, ﬂexible, and component based CA to be used stand-‐alone or integrated in other JEE applicaBons. • hcp://www.ejbca.org Features: • hcp://www.ejbca.org/features.html • PKI features: MulBple CAs, Sub CAs, PKIX compliant, PKCS compliant, … • ePassport PKI features: support for BAC PKI, Country Signing CA (CSCA) and Document Signer (DS) cerBﬁcates. Support EAC PKI, Country Verifying CA (CVCA) and Document Veriﬁers (DV) issuing InspecBon System (IS) cerBﬁcates. • Integra-on features: Built on the JEE 5 (EJB 3.0) speciﬁcaBon, Web service (WS) interface for remote administraBon and integraBon. API for an external RA, restricBng in-‐bound traﬃc to CA. Hard token module for integraBng with hard token issuing system (smart cards).
6. FOSS Crypto products 5. The Sirius Signing Server • hcp://sirius-‐sign.sourceforge.net • hcps://sirius.atlassian.net • Sirius Server is a signing and veriﬁcaBon soNware suite with its focus on high throughput and easy integraBon into an exisBng IT landscape. • In compliance with the European Digital Signature guidelines for signature creaBon smartcards with OCF and PKCS11, these interfaces are supported by the server. • This open source version supports soN cerBﬁcates. • A test cerBﬁcate is provided within the soNware in the sourceforge repository. • An EJB container is required and provided in the repository. Features: • It implements the OASIS DSS standard • Enable mass digital signing in compliance with PKCS7 and XMLDSig • J2SE/W3C widget code signing • MulBple import and export interfaces
6. FOSS Crypto products 6. OpenSign • Is a collecBon of Java Applets providing client-‐side digital signing funcBonality using x.509 cerBﬁcates. • It currently consists of two applets, one for signing plain ASCII text and another providing login funcBonality. • hcp://www.openoces.org/opensign/index.html Features: • digital signing of text • logon funcBonality • support for x.509 cerBﬁcates stored in PKCS12s • support for x.509 cerBﬁcates stored in the MicrosoN Windows Keystore (CAPI) • support for the naBve MicrosoN Java virtual machine • works in all common browsers: Firefox, Internet Explorer, Mozilla, Safari, etc. • has a small footprint: The core applet is less than 100KB. • has localizaBon support
6. FOSS Crypto products 7. CryptoApplet • Is a Java applet for advanced digital signature creaBon. • hcp://proyectosBc.uji.es/pr/cryptoapplet The signature representaBon formats supported by CryptoApplet are the following: • Raw signature. • CMS/PKCS#7. • XAdES-‐X-‐L in DigiDoc format. • PDF signature. CerBﬁcate management is done transparently for the user through direct access to CryptoAPI, if we are using MicrosoN Internet Explorer, or to PKCS#11 if we are using Firefox (either in Windows or GNU/Linux). Stored cerBﬁcates can also be used if the client system has the Clauer soNware installed. The applet can also be executed in the operaBng systems MicrosoN Windows XP and GNU/Linux, the only requirement being having Suns Java Virtual Machine (version 1.5 o higher) installed.
6. FOSS Crypto products 8. Open eSignForms • Is the ﬁrst free and open source, web contracBng soNware applicaBon (on-‐premise) and SaaS (hosted). • hcp://www.openoces.org/opensign/index.html Open eSignForms can help your school, non-‐proﬁt, medical facility, or business go green by improving on your paperless acBviBes. Just use any of our free forms to help with secure document delivery with external parBes and e-‐docs to storing ﬁles and scanned paperwork (fully encrypted) for your own secure access from anywhere in the world.
6. FOSS Crypto products 9. OpenXAdES • OpenXAdES is technology that enables people to work with legally binding digital signatures. • hcp://openxades.org OpenXAdES is: • Document format. OpenXAdES speciﬁes the format that is used for storing original signed documents (in any format), signatures given to those documents and the associated technical informaBon. It is based on the XML-‐ DSIG (XML Digital Signatures) standard by W3C and XAdES (XML Advanced Electronic Signatures) technical standard published by ETSI (European TelecommunicaBon Standards InsBtute). • Program libraries. OpenXAdES provides libraries in C and Java for document creaBon, signing and veriﬁcaBon. OpenXAdES libraries are used for end-‐user tools currently branded as "DigiDoc”: • Client program. DigiDoc Client is a simple Windows client program for working with OpenXAdES documents. • Web portal. Portal soNware is based on the OpenXAdES libraries and lets people work with digital documents and signatures without the need to install any addiBonal soNware. Both the client and the portal are based on the same OpenXAdES libraries that are made available for other developers in the download area. DigiDoc Portal is available for users with Estonian ID-‐card.
7. Architecture for Crypto SOA Web Portal Mobile B2B / B2C CRYPTO WS Srvc1 Srvc2 Srvc3 Srvc4 Srvc5 Srvc6 Srvc7 Srvc8 Srvc9 Srvc10 Authentication Enterprise Service Bus Activity Authorization Monitoring SSO Identity Mngmt ADAPTERS SRV1 SRV2 SRV3 SRV4 SRV5 SRV6 SOAP REST JMS IDOC FTP JMS CMS ERP CRM BPMCertification -Time Server Hardware Digital Time PDF Secure DigitalAuthority -OCSP Security Signature Stamp Signature Archiving Signature(PKI) Module (HSM) Creator Creator Creator Validator BI Trusted Third Party (TTP) and Cryptography Services Existing and Legacy Apps
8. Use Case#1: Signing in the client side Client/Applet Liferay/DocLib WSO2 ESB/Proxy TTP/Validator 1 User want to sign a document with his private and public key 1 stored in his Smart Card. 2 The Applet creates hash and when are creaBng signature, it 3 2 calls to TTP for validaBng keys/cerBﬁcates (OCSP, Time Stamp, CRL, …). 4 Liferay is a place to store document, signed documents, 5 3 sigantures, etc. WSO2 ESB is just a WS Proxy. 4 TTP is the validator of idenBBes (keys/cerBﬁcates), status of 5 credenBals (cerBﬁcate is or not revoked?, OCSP, CRL, …). Document Library ESB CA, TSA, OCSP, … Users TTP gives us a trust Bme (Time Stamping).
9. Use Case#2: Signing in the server side Client Liferay/DocLib WSO2 ESB/Proxy TTP/Validator User wants document to be signed. 1 1 User sends document to be signed. 2 3 Liferay receives the document and save it, then It calls to WSO2 2 ESB for creaBng signature. WSO2 receives signing request and It prepares the creaBon of 4 5 3 signature (get Bme stamp, validate keys/cerBﬁcate, …) 6 4 TTP sends informaBon on status of validaBon to WSO2 ESB. 5 WSO2 ESB creates signature if status of validaBon was OK. 6 Liferay receives the signed document, as a repository document assures integrity, conﬁdenciality and privacy. Users Document Library CA, TSA, OCSP, … ESB
10. Use Case#3: Time Stamping Client Liferay/DocLib WSO2 ESB/Proxy TTP/Validator The user wants to store a document in the repository 1 1 2 Liferay receives the document and save it, then It calls to WSO2 2 ESB for creaBng Bme stamp. WSO2 receives Bme stamping request and re-‐send to TTP. 4 3 In this case WSO2 ESB is just a Proxy, but could replace TTP. 5 TTP sends Bme stamping (signature) to Liferay. WSO2 ESB 4 knows if request was responded. Liferay receives response message (Bme stamping) and saves it 5 inside. Users Document Library ESB CA, TSA, OCSP, … Atomic Clock
12. Business Cases ¤ Any process looking Content ¤ Cer-ﬁed for non-‐repudia-on Documents ¤ Long ¤ DRM Digi-za-on of Term Archive Documents Archiving ¤ E-‐Invoice ¤ E-‐Notary ¤ E-‐Burofax ¤ Records Management Processes Workﬂow
13. Demo / Proof of Concept “Document Time Stamping” • Read Document • Sign request with TSA’s cerBﬁcate • Send request to TSA • Receive response and store in DocLib
14. Conclusions 1. You need large investments to ensure security on our systems? -‐ not, do not! • Exists standards • Exists crypto frameworks, libraries, etc. • Exists free open source crypto apps • You can build robust and secure ApplicaBons on top of WSO2 pla4orm 2. Why not use WSO2 API to create a Crypto API. -‐ Yes,we can.
Roger CARHUATOCTO IT & FOSS Consultant SOA, BPM, ECM, Portal and Security. You can reach me on: holisticsecurity.worpress.com roger [AT] konosys.es +34 629292125 @chilcano www.linkedin.com/in/rcarhuatocto