Java Security Web Services Security (Overview)Java 2 CryptographyJCA + JCEJCA + JCE PrinciplesSlide 5ProvidersProviders ImplementationProvidersConfiguration and ManagementEngine and SPISlide 11Slide 12Enterprise Security for Web ServicesWeb ServiceXMLSOAPSlide 17Security TechnologiesXML SignatureXML Signature StructureXML Signature: Enveloping SignatureXML Signature: Enveloped SignatureXML Signature: Detached SignatureSlide 24XML Encryption StructureXML Encryption: ExampleSlide 27SAMLSAML - scenarioSlide 30SAML – how it worksSAML ExampleSAML protocolSAML Authorization/Attribute AssertionsSAML ArchitectureSAML ProtocolSlide 37Slide 38SAML BindingWS-SecurityHTTP Transport Security Versus Message SecurityHTTP-TS Pros and ConsMessage Security Pros and ConsWeb Services Security StackJava Security Web Services Security (Overview)Lecture 9Java 2 CryptographyJava provides API + SPI for crypto functionsJava Cryptography ArchitectureSecurity related core classesAccess control and cryptographyJava Cryptography ExtensionOther core classesMessage digest, digital signatures, certificate managementKey exchange, MACJCA + JCEEngineAbstract cryptographic service: E.g., message digest, digital signaturesTo provide cryptographic operationsTo generate or supply the crypto materialTo generate and manage data objects (certificates or keys – keystores)Use instances of engine class for crypto operationsAlgorithmImplementation of an engine: Eg. MD5 for MessageDigestProvider(set of) packages that supply concrete implementation of a subset of the cryptographic services (DS, MD, etc.)JCA + JCE Principles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 runtimeImplementation independenceImplementation independenceAlgorithm IndependenceAlgorithm IndependenceEngine ClassSPI class implemented by PsImplementations expose the same APIMessageDigest.getIntance(MD5)JCA + JCE PrinciplesAlgorithm ExtensibilityAlgorithm ExtensibilityImplementation interoperabilityImplementation interoperabilityVarious implementation can work with one anotherUse one another’s keysVerify one another’s messagesNew algorithms can be easily plugged inHas to be compliant with the MessageDigest APIProvidersSPI is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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 implementProviders ImplementationConcept of provider classProvider class in java.security – abstract classMust be subclassed by providersConstructor sets the values to help look up algorithmsmain provider – if it implements all the SPI methods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getInstance() of the corresponding Engine class is called, optionally Provider is indicatedProvidersgetInstance() relies on java.security.Security class to search the registered providers in java.security filesecurity.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.IBMCertPathConfiguration and ManagementCopy the provider pakckageJAR file in application/boot/extension class pathConfigure the ProviderStatic: in java.security file; order is importantEffective in Java runtime – read once.Dynamic: addProvider() insertProvederAt()To change position – removeProvider() then addNeed permission “insertProvider.name”Engine and SPIEngine classes are the interfaces between the user code and the implementationsImplementations are found at runtimeEngine and SPIThe engine class calls the SPI class methodsSPI class method names begins with “engine”Implementation of abstract SPI done by providersEncapsulated as private fieldEnterprise Security for Web ServicesXMLSimplicity and flexibilityFacilitates B2B messagingSecurity is a big concernStructured semantics and schema-driven natureXML security technologies are availableEncryption Elements, sectionsDigital signaturesAll or parts – by one or more entitiesAccess controlWeb ServiceWeb service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XML Structured semantics and schema driven naturePolicies can be expressed in XML by orgs for Changed back to platform specific enforcement mechanismEncryptions can be employedSections, all parts signed, etc.Trading Partner Agreements, SAML and XACMLSOAPSimple, lightweight and extensible XML-based mechanism for exchanging structured data between network applicationsConsists of:An envelop What is in the message and who should deal with itA set of encoding rules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 HTTPSOAPIt supports modular architectureAllows defining the following in separate documentsWS Addressing Specification (WS-Addressing)WS Security Specification (WS-Security) A SOAP envelope is defined inEnvelope XML element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 informationSecurity TechnologiesXML SignatureValidation of the messages and non-repudiationSAMLAuthM + Security Srvices MLAuthentication + Authorization profile informationCommon language for sharing of security