T-110.5140 Network Application Frameworks and XML
Web Service Security
Based on slides by Pekka Nikander
AnnouncementsA list of papers to read for the final exam Bob Braden, Architectural Principles of the Internet, IPAM Tutorial March 12, 2002. Jukka Ylitalo and Pekka Nikander, A new Name Space for End-Points: Implementing secure Mobility and Multi-homing across the two versions of IP, in Proceedings of the Fifth European Wireless Conference, Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441, Barcelona, Spain, February 24-27, 2004. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. OpenDHT: A Public DHT Service and Its Uses. Proceedings of ACM SIGCOMM 2005. August 2005.
ContentsWeb service securitySecurity contextsReviewWS-Security Standard SAMLXACMLSummary
Web Services Security RequirementsProtect messaging across domainsConvey security information in messagesMake security decisions and communicate them between partiesTools at handWS-Security, XML-SignatureSAMLXACMLDigital certificate validationContent-filtering XMLFilters based on data format (XSD)Filters based on content (XPath)Filters based on integrity (XML Signature)
Functional point of viewRoutingIntegrityValidationContent CheckingAuthenticationAuthorization ManagementConsole
Design andDeploySecuritypoliciesID ManagementLDAPPKISingle Sign-OnReportingActivityAlertingSecure logging
Security Contexts in Web ServicesRemember Web Services goals:Re-use existing servicesCombine services from several domainsSecurity result: Must support several security domainsSOAP intermediariesReusing security tokens from one message in another message
Example 1: Pass subject detailsWeb BrowserWebsiteAppl.ServerWeb ServiceMain Point: We need security within AND between security contexts!
Example 2: SOAP RoutingMain Point: We need XML validation, encryption, and authentication between security contexts!
Standardization GroupsXML EncryptionXML SignatureXKMSXrMLWS-SecurityProvisioningBiometricsXACMLSAML
Digital SignaturesMessageNeed to know the message, digest, and algorithm (f.e. SHA1)
XML Digital Signatures (cont.)
(()? )+ ()? ()*
? ? ? ? ? ? ? ? ?
WS Security IWeb Services Security: SOAP Message Security 1.0 (Oasis Standard 2004)1.1 (Oasis Standard 2006)Extensions in: security token support, message attachments and rights management. End-to-End securityHeaders are decrypted and processed as neededSelective processingSome parts are plain textSome are encryptedSome are signedHow does it work?SOAP header carries security information (and other info as well)
WS Security IIAbility to send security tokens as part of a message, message integrity, and message confidentialitySecurity model in terms of security tokens combined with digital signatures to protect and authenticate SOAP messagesAn X.509 is an example of a signed security token endorsed by a CA.When third party support is not available, receiver may choose to accept the claims in the token based on trust on the entity that sent the message.
GoalsMultiple security token formatsMultiple trust domainsMultiple signature formatsMultiple encryption technologiesEnd-to-end message content security and not just transport-level security
Non-goalsEstablishing a security context or authentication mechanismKey derivationAdvertisement and exchange of security policyHow trust is established or determinedNon-repudiation
Message ProtectionIntegrity mechanism designed to support multiple signaturesUses XML Signature and XML EncryptionSyntax and semantics of signatures within a elementThis is the security block in the SOAP headerSOAP actor/role attribute is used to target header blocksSecurity element includes Security tokensInformation about the use of XML Encryption & Signature in the SOAP header/body/combination
Security HeaderMay be present multiple times in a SOAP messageMust have different actor/role attribute values
Unrecognized extension elements or attributes should cause a faultReceivers MAY ignore elements or extensions within the element, based on local security policy. But they must understand them first
Security Element: enclosing informationUsernameToken blockDefines how username-and-password info is enclosed in SOAPPassword must be protected against eavesdroppers (enc) and replay (timestamp/nonce)BinarySecurityToken blockEncloses binary dataAn X.509 certificate or a Kerberos ticketHas an identifier (Id), a value (ValueType), and an encoding (EncodingType)XML Signature KeyInfo may point to a certificate used in signing using a Reference to its Id.Similar for XML Encryption.So we can sign/encrypt data with a certificate in the header.
ID ReferencesA new global attribute: wsu:Id attribute..Note that the SOAP processor needs to support thiswsu:id a WS-Security namespace (wssecurity-secext-1.0.xsd)Recipients do not need to understand the full schema of the message for processing the security elementsTwo wsu:Id attributes within an XML document MUST NO have the same valueRecommended that wsu:Id is used instead of a more general transformation, especially XPath
SignaturesDoes not use the Enveloped Signature TransformSo sig does not envelope signed dataDue to mutability of SOAP headerDoes not use the Enveloping SignatureSo sig is not appended as a child to the documentThe sig is appended to the security blockExplicitly include the elements to be signedAllows for extensions, multiple signatures, etc.
CanonicalizationXML Canonicalization and Exclusive XML CanonicalizationProblemsXML tools change documents, e.g. duplicate namespace declarations can be removed or createdSignature simply covers something like xx:foo, its meaning may change if xx is redefinedThere are mechanisms like XPath, which consider xx=http://example.com; to be different from yy=http://example.com/
Inclusive CanonicalizationCopies all the declarations that are currently in forceUseful in the typical case of signing part or all of the SOAP bodyCauses problems for signatures when the context changes (for example by intermediaries)
Exclusive CanonicalizationTries to figure out what namespaces are actually used and just copies thoseDoes not look into attribute values or element contentCan happen implicitly because XML processing tools will add xsi:type if schema subtypes are usedUseful when you have an XML document that you wish to insert into another XML documentExample: signed SAML assertionShould be used with WS-Security: SOAP Message Security (recommended)
Signing MessagesMultiple signature entries MAY be added into a single SOAP Envelope within one header blockMUST be prepended to the existing content elements contained in the signature should refer to a resource within the enclosing SOAP envelope
How to locate a key in a security token?Extensible mechanism that provides an open content model for referencing security tokensSpecification considers only use in a header blockNew reference option for XML signatureSTR Deference TransformApplied to a SecurityTokenreferenceMeans that the output is the token referenced by the element, not the element itselfYou can conveniently locate and sign security tokens anywhere in the header
ExampleSOAP EnvelopeSOAP HeaderWS SecuritySecurity token (a certificate)Encryption key (passing symmetric key)SignatureSOAP BodyEncrypted content
Overall message structure
... ... ... ... ... 18.104.22.168.
1. Binary security token
2. Passing encryption key
We are using another certificate for asymmetric crypto. This one is for symmetricEncrypted symmetric keyReference to cipher data
3. Actual signature
... ... . .....
Exclusive canonicalizationReferences & digests to dataReference to certificate.
3. SignedInfo in more detail
4. Actual message body
Error HandlingSOAP Faults are used to indicate faultsError scenariosSecurity token type unsupportedNote: WS-Policy may be used to convey what security tokens can be understood by different partiesFault code: InvalidSecurity (if contents of the header block cannot be processed)Invalid security tokenFor example: security token corrupted or has invalid signatureFault code: InvalidSecurityTokenSecurity token cannot be authenticatedFor example: given certificate cannot be validatedFault code: FailedAuthenticationSecurity token unavailableFor example: a certificate was referenced that could not be locatedFault code: wsse:SecurityTokenUnavailable
Extensions in 1.1Builds on 1.0WS-Security 1.1 extensions include EncryptedKeyToken security tokenRepresents a security token for an encrypted symmetric key. EncryptedHeader blockProtect any header block, also nestedDigital signature confirmationA digital signature confirmation is a SOAP message that a Web service sends to a client that confirms that it verified the client's digital signature.
SAMLSAML (Security Assertion Markup Language) A XML-based framework (schemas) for the exchange of authentication and authorization information A standard message exchange protocolHow you ask and receive informationMainly for integration, up to relying parties to decide to what authentication authority to trustAssertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources Authentication statements merely describe acts of authentication that happened previously Specified by OASIS
SAML in a nutshellXML-based framework for exchanging security informationXML-encoded security assertionsXML-encoded request/response protocolRules on using assertions with standard transport and messaging frameworksSAML & WS-Security allow a SOAP message to include information about the end-users authentication status
SAML Motivation: Portable Trust Using services in B from A?Authentication at B?Not acceptable!
Authenticationserver CTimed updatesTimed updates
SAML assertionsAn assertion is a declaration of fact about a subject, e.g. a userAccording to some assertion issuesSAML has three kinds, all related to security:AuthenticationAttributeAuthorization decisionYou can extend SAML to make you own kinds of assertionsAssertions can be digitally signed
All assertions have some common informationIssuer and issuance timestampAssertion IDSubjectName plus the security domainOptional subject information, e.g. public keyConditions under which assertion is validSAML clients must reject assertions containing unsupported conditionsSpecial kind of condition: assertion validity periodAdditional adviceE.g. to explain how the assertion was made
Authentication assertionAn issuing authority asserts that:Subject Swas authenticated by means Mat time TCaution: actually checking or revoking of credentials is not in the scope of SAML!Password exchangeChallenge-responseEtc.It merely lets you link back to acts of authentication that took place previously
Example authentication assertion
Attribute assertionAn issuing authority asserts that:subject Sis associated with attributes A,B,..with values a,b,Typically this would be gotten from an LDAP repositoryjohn.doe in example.comis associated with attribute Departmentwith value Human Resources
Example attribute assertion
Authorization decision assertionAn issuing authority decides whether to grant the requestby subject Sfor access type Ato resource Rgiven evidence EThe subject could be a human or a programThe resource could be a web page or a web service, for example
Example authorization decision assertion
XACMLXACML 2.0 and all the associated profiles were approved as OASIS Standards on 1 February 2005. XACML defines three top-level policy elements: , and . The element contains a Boolean expression that can be evaluated in isolation, but that is not intended to be accessed in isolation by a PDP. So, it is not intended to form the basis of an authorization decision by itself. It is intended to exist in isolation only within an XACML PAP, where it may form the basic unit of management, and be re-used in multiple policies.The element contains a set of elements and a specified procedure for combining the results of their evaluation. It is the basic unit of policy used by the PDP, and so it is intended to form the basis of an authorization decision.Defines algorithms arriving at an authorization decision given the input rules and policies
Source: http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdfPermit or denyBoolean expressionAn operation that should be performed by the PEP in conjunction with the enforcement of authorization decision
SAML and XACMLPEPPolicy Enforcement PointWeb ServicePDPPolicy Decision PointPRPPolicy Retrieval PointPIPPolicy Information PointPolicy Store(XACML)PAPPolicy Admin. PointRules are combined: subjects, resources, and attributes. Exported into XACML.PDP queries attributes from PIP (time of day, value, etc.). PIP returns an attribute assertion.Once the PDP has all the relevant information, it evaluates rules and returns a SAML authoriz. AssertionOnce the SAML authoriz. Has ben made it may be included into the SOAP message and used by the target WS.SOAP msg isIntercepted. SAML query is formed, results determine access. Identity info taken from request. There may be multiple PEPs.
ImplementationsTrust Services Integration Kit (TSIK), Verisign Java API for creating trusted services, includes a SAML API http://www.xmltrustcenter.org/developer/verisign/tsik/index.htmApache XML-Security, Apache Software Foundation XML Digital Signature and XML Encryption (Java, C++) http://xml.apache.org/security/Web Services Enhancements 2.0, Microsoft.NET implementation of various WS Security specs.http://msdn.microsoft.com/webservices/building/wse/Microsoft Passport, Microsoft Single sign-on support XML Security Suite, IBM XML Digital Signature, XML Encryption and XML Access Control Language (Java)http://www.alphaworks.ibm.com/tech/xmlsecuritysuiteSunONE Identity Server, Sun Microsystems Supports Libertys federated identity and SAML
Web Services Enhancements 3.0Implements many of the rules of the WS-* specificationsWorks with HTTP and SOAP (SoapExtensions)Supported specificationsWS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust, WS-Referral, WS-Addressing, WS-Policy, WS-Attachments3.0 supports WS-Security 1.1Supports signing/encrypting message elements and policiesOverviewhttp:/...