Java Security Web Services Security Overview Lecture 9

Java Security Web Services Security (Overview) Lecture 9

Java 2 Cryptography l Java provides API + SPI for crypto functions l Java Cryptography Architecture l Security related core classes § l Access control and cryptography Java Cryptography Extension l Other core classes § § Message digest, digital signatures, certificate management Key exchange, MAC

JCA + JCE l Engine l Abstract cryptographic service: E. g. , message digest, digital signatures l To provide cryptographic operations l To generate or supply the crypto material l To generate and manage data objects (certificates or keys – keystores) § l Algorithm l l Use instances of engine class for crypto operations Implementation of an engine: Eg. MD 5 for Message. Digest Provider l (set of) packages that supply concrete implementation of a subset of the cryptographic services (DS, MD, etc. )

JCA + JCE Principles l l Provider based architecture Vendors can register implementations of algorithms Providers can be configured declaratively so the application code does not need to change Allows different implementations to be found at runtime Implementation independence l l Engine Class SPI class implemented by Ps l Implementations expose the same API Message. Digest. get. Intance(MD 5) Algorithm Independence

JCA + JCE Principles l New algorithms can be easily plugged in l Has to be compliant with the Message. Digest API l Various implementation can l l l work with one another Use one another’s keys Verify one another’s messages Implementation interoperability Algorithm Extensibility

Providers l SPI is l l l Key to pluggability, extensibility and module independence It is a set of Java-language interfaces and abstract classes for cryptographic services A Provider is a pluggable module l l Provides concrete implementations of some SPI methods java. security and javax. crypto and their subpackages contain many SPI interfaces that JCA and JCE providers can implement

Providers Implementation l Concept of provider class l Provider class in java. security – abstract class l Must be subclassed by providers Constructor sets the values to help look up algorithms main provider – if it implements all the SPI methods l l § § l Every provider should have one master class –must have a default constructor so as to be loaded when JVM starts up Property/value (SPI label, corresponding class that implements it) For cryptographic service l get. Instance() of the corresponding Engine class is called, optionally Provider is indicated

Providers get. Instance() relies on java. security. Security class to search the registered providers in java. security file security. provider. 1=com. ibm. jsse. IBMJSSEProvider security. provider. 2=com. ibm. crypto. provider. IBMJCE security. provider. 3=com. ibm. security. jgss. IBMJGSSProvider security. provider. 4=com. ibm. security. cert. IBMCert. Path

Configuration and Management l Copy the provider pakckage l l JAR file in application/boot/extension class path Configure the Provider l Static: in java. security file; order is important § l Effective in Java runtime – read once. Dynamic: add. Provider() insert. Proveder. At() § To change position – remove. Provider() then add § Need permission “insert. Provider. name”

Engine and SPI l l Engine classes are the interfaces between the user code and the implementations Implementations are found at runtime

Engine and SPI l The engine class calls the SPI class methods l l SPI class method names begins with “engine” Implementation of abstract SPI done by providers Encapsulated as private field

Enterprise Security for Web Services l XML l l l Simplicity and flexibility Facilitates B 2 B messaging Security is a big concern l l Structured semantics and schema-driven nature XML security technologies are available l l l Encryption l Elements, sections Digital signatures l All or parts – by one or more entities Access control

Web Service l Web service l l Is a an interface that describes a collection of network-accessible operations based on open internet standards Potential to enable application integration at a higher level of the protocol stack based on Web Services standards § § XML Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) Universal Description, Discovery and Integration (UDDI)

XML l l Structured semantics and schema driven nature Policies can be expressed in XML by orgs for l l Encryptions can be employed l l Changed back to platform specific enforcement mechanism Sections, all parts signed, etc. Trading Partner Agreements, SAML and XACML

SOAP l l Simple, lightweight and extensible XML-based mechanism for exchanging structured data between network applications Consists of: l An envelop § l A set of encoding rules § l What is in the message and who should deal with it Serialization mechanism that can be used to exchange instances of application defined data types Can be used in (re-enveloped) with other protocols such as HTTP

SOAP l It supports modular architecture l l Allows defining the following in separate documents l WS Addressing Specification (WS-Addressing) l WS Security Specification (WS-Security) A SOAP envelope is defined in l Envelope XML element l Consists of two parts: § Header: adds features to the messages Meta information can be added to the message § E. g. , transaction IDs, message routing information, message security § § Body: mechanism for exchanging information

Security Technologies l XML Signature l l Validation of the messages and non-repudiation SAML l Auth. M + Security Srvices ML § l l Common language for sharing of security services between companies for B 2 B/B 2 C transacrtions XML Encryption l l Authentication + Authorization profile information Encrypting of XML fragments WS-Security l Set of SOAP extensions that can be used when building WS to implement integrity and confidentiality

XML Signature l l IETF and W 3 C standard for digitally signing all or some part of the XML document XML Signature l l Is itself a piece of XML – defined by a schema Contain references – URIs – to what is being signed l l URIs – within the document or external to it A single XML document may have multiple signatures

XML Signature Structure l XML Signature contains four major items: l A set of pointers (references) to things to be signed l The actual signature l (Optional) The key (or a way to look up the key) for verifying the signature l (Optional) An Object tag that can contain miscellaneous items not included in the first three items < S i g n a t u r e I D ? > < S i g n e d I n f o > (Canonicalization. Method) (Signature. Method) (<Reference (URI=)? > (Transforms)? (Digest. Method) (Digest. Value) </Reference>)+ < / S i g n e d I n f o > (Signature. Value) ( K e y I n f o ) ? ( O b j e c t I D ? ) * < / S i g n a t u r e > <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="http: //www. foo. com/secure. Document. html" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature>

XML Signature: Enveloping Signature l <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="#111" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> <Object> <Signed. Item id="111">Stuff to be signed</Signed. Item> </Object> l </Signature> l l l

XML Signature: Enveloped Signature <Purchase. Order id="po 1"> <SKU>125356</SKU> <Quantity>17</Quantity> <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="#po 1" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature> </Purchase. Order> Parent element

XML Signature: Detached Signature <Purchase. Order. Document> <Purchase. Order id="po 1"> <SKU>12366</SKU> <Quantity>17</Quantity> </Purchase. Order> <Signature xmlns= "http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="#po 1" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature> </Purchase. Order. Document>

XML Signature: Detached Signature Can also reference external source <Signature xmlns= "http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI= "http: //www. foo. com/Lion. jpg" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature>

XML Encryption Structure <Encrypted. Data Id? Type? Mime. Type? Encoding? > <Encryption. Method/>? <ds: Key. Info> <Encrypted. Key>? <Agreement. Method>? <ds: Key. Name>? <ds: Retrieval. Method>? <ds: *>? </ds: Key. Info>? <Cipher. Data> <Cipher. Value>? <Cipher. Reference URI? >? </Cipher. Data> <Encryption. Properties>? </Encrypted. Data> - - Could encompass an entire document of other XML structure (similar to Enveloping structure) Could contain a pointer to a detached resource

XML Encryption: Example <Employee> <Name>Dave Remy</Name> <Social. Security. Number> <Encrypted. Data Type= "http: //www. w 3. org/2000/09/xmldsig#content"> <Encryption. Method Algorithm=". . . "> <Cipher. Data><Cipher. Value>. . . </Cipher. Value> </Cipher. Data> </Encrypted. Data> </Social. Security. Number> <Salary> <Encrypted. Data Type= "http: //www. w 3. org/2000/09/xmldsig#content"> <Encryption. Method Algorithm=". . . "> <Cipher. Data><Cipher. Value>. . . </Cipher. Value> </Cipher. Data> </Encrypted. Data> </Salary> </Employee>

XML Encryption: Example <Employee> <Name>Dave Remy</Name> <Social. Security. Number> <Encrypted. Data id="socsecnum" Type="http: //www. w 3. org/2000/09/ xmldsig#content"> <Encryption. Method Algorithm=". . . " /> <Cipher. Data><Cipher. Value>. . . </Cipher. Value></Cipher. Data> </Encrypted. Data> </Social. Security. Number> <Salary> <Encrypted. Data id="salary" Type="http: //www. w 3. org/2000/09/ xmldsig#content"> <Encryption. Method Algorithm=". . . "> <Cipher. Data><Cipher. Value>. . . </Cipher. Value></Cipher. Data> </Encrypted. Data> </Salary> <Encrypted. Key> <Encryption. Method Algorithm=". . . " /> <Cipher. Data> <Cipher. Value>. . . </Cipher. Value> </Cipher. Data> <Reference. List> <Data. Reference URI="#socsecnum" /> <Data. Reference URI="#salary" /> </Reference. List> </Encrypted. Key> </Employee>

SAML l Enables portable identities and the assertions that these identities want to make l l Assertion: authentication; authorization SAML is important for WS l l is a standard XML format – all normal XML tools apply to SAML Includes a standard message exchange protocol Specifies the rules for how it is transported – making interoperability explicit at the specification level Expression of security in the form of assertions about subjects (different from Certification authority based approach) – facilitated Single-Sign ON

SAML - scenario l Federated identity

SAML l Defines three types of assertions l Authentication l States that a particular authentication authority has authenticated the subject § § l l Using a particular process At a particular time (+ validity) Authorization l States that a particular authority has granted/denied permissions on particular resource (+time) Attributes l Provides qualifying information about either an authentication or authorization assertion

SAML – how it works l Three XML based mechanisms and their relationship XML schema + definition Rules on using assertions

SAML Example <saml: Assertion> Major. Version="1" Minor. Version="0" Assertion. ID="192. 168. 0. 1. 12345" Issuer="Company. com" Issue. Instant="2004 -01 -21 T 10: 02: 00 Z"> <saml: Conditions> Not. Before="2004 -01 -21 T 10: 02: 00 Z" Not. After="2004 -01 -21 T 10: 09: 00 Z" /> <saml: Authentication. Statement> Authentication. Method="password" Authentication. Instant="2004 -01 -21 T 10: 02: 00 Z"> <saml: Subject> <saml: Name. Identifier Security. Domain="Company. com" Name="jothy" /> </saml: Subject> </saml: Authentication. Statement> </saml: Assertion>

SAML protocol l SAML assertions are sent to the authentication and authorization authorities

SAML Authorization/Attribute Assertions <saml: Assertion. . . > <saml: Attribute. Statement> <saml: Subject>. . . </saml: Subject> <saml: Attribute. Name="Paid. Status" Attribute. Namespace="http: //smithco. com"> <saml: Attribute. Value> Paid. Up </saml: Attribute. Value> </saml: Attribute> <saml: Attribute. Name="Credit. Limit" Attribute. Namespace="http: //smithco. com"> <saml: Attribute. Value xsi: type="my: type"> <my: amount currency="USD">500. 00 </my: amount> </saml: Attribute. Value> </saml: Attribute. Statement> </saml: Assertion> <saml: Assertion. . . > <saml: Authorization. Statement Decision="Permit" Resource="http: //jonesco. com/doit. cgi"> <saml: Subject>. . . </saml: Subject> <saml: Action Namespace= "urn: oasis: names: tc: SAML: 1. 0: action: rwedc">Execute </saml: Action> </saml: Authorization. Statement> </saml: Assertion>

SAML Architecture

SAML Protocol l Authentication Query <samlp: Request Major. Version="1" Minor. Version="0" Request. ID="128. 14. 234. 20. 12345678" Issue. Instant="2001 -12 -03 T 10: 02: 00 Z"> <samlp: Respond. With>saml: Authentication. Statement</samlp: Respond. With> <ds: Signature>. . . </ds: Signature> <samlp: Authentication. Query> <saml: Subject> <saml: Name. Identifier Security. Domain="Company. com" Name="jothy" /> </saml: Subject> </samlp: Authentication. Query> </samlp: Request>

SAML Protocol l Attribute Query <samlp: Request. . . > <samlp: Attribute. Query> <saml: Subject>. . . </saml: Subject> <saml: Attribute. Designator Attribute. Name="Paid. Status" Attribute. Namespace="http: //smithco. com"/> </samlp: Attribute. Query> </samlp: Request>

SAML Protocol l Authorization Assertion <samlp: Request. . . > <samlp: Authorization. Decision. Query Resource="http: //Chosen. Travel. com/reserve_hotel. cgi"> <saml: Subject> <saml: Name. Identifier Security. Domain="Company. com" Name="joeuser" /> </saml: Subject> <saml: Actions Namespace="urn: oasis: names: tc: SAML: 1. 0: action: rwedc"> <saml: Action>Execute</saml: Action> </saml: Actions> <saml: Evidence> <saml: Assertion>. . . </saml: Assertion> </saml: Evidence> </samlp: Authorization. Decision. Query> </samlp: Request>

SAML Binding l l l Requires SOAP over HTTP as one binding SOAP Binding l SAML information is contained inside the SOAP SAML Profile l Describes how SAML assertions are embedded into and extracted from a framework/protocol l Browser profile of SAML profile SOAP WS-Security - Binding: is a mapping of SAML request/response message exchanges into standard comm protocols; - to transport SAML messages to SAML authorities

WS-Security l Focuses on applying existing security technologies to SOAP message l l l X. 509 certificates SAML assertions XML Signatures XML Encryption GOAL: Secure the SOAP l l No matter where it goes No matter how long it lives

HTTP Transport Security Versus Message Security l HTTP Transport Layer Security l l Authentication at the time secure pipe is created Confidentiality/Integrity in the pipe only

HTTP-TS Pros and Cons l Pros Cons l Mature: Tried and true Support: Supported by most servers and clients Understood: Understood by most system administrators Simpler: Generally simpler than message-level security alternatives l l l l Point to Point: Messages are in the clear after reaching SSL endpoint Waypoint visibility: Cannot have partial visibility into the message Granularity: Cannot have different security for messages in and messages out Transport dependent: Applies only to HTTP

Message Security Pros and Cons l Pros Cons l Persistent: Allows the message to be selfprotecting Selective: Portions of the message can be secured to different parties Flexible: Different security policy can be applied to request and response Transport independent l l Immature: standard, tools Complex: encompasses many other standards including XML Encryption, XML Signature, X. 509 certificates, and many more

Web Services Security Stack