T-110.455 Network Application Frameworks and XML Web Service Security 06.04.2005 Sasu Tarkoma Based on slides by Pekka Nikander

  • Published on

  • View

  • Download

Embed Size (px)


  • T-110.455 Network Application Frameworks and XML

    Web Service Security


    Sasu Tarkoma

    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. Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Michael Walfish, "A Layered Naming Architecture for the Internet", ACM SIGCOMM 2004, Portland, OR, September 2004. We will have an invited lecture on 13.04. by Jaakko Kangasharju on wireless web services. Everyone should attend!

  • ContentsReviewRequirementsSecurity contextsWS security standard revisitedSAMLSummary

  • Standardization GroupsXML EncryptionXML SignatureXKMSXrMLWS-SecurityProvisioningBiometricsXACMLSAMLSecurity Assertion Markup languageXML Common Biometric Format (XCBF)Extensible Rights Markup LanguageeXtensible Access Control Markup Language (XACML)XML Key Management Specification

  • Digital SignaturesMessageNeed to know the message, digest, and algorithm (f.e. SHA1)

  • XML Digital Signatures (cont.)

    (()? )+ ()? ()*

  • Encryption

  • XML Encryption

    ? ? ? ? ? ? ? ? ?

  • Web Services Security RequirementsAccess control to Web servicesWS-Security, XML-SignatureSAML Issuing and validation of SAML assertionsDigital 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!

  • WS Security IWeb Services Security: SOAP Message Security 1.0 (Oasis Standard 2004)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

    .. ...

  • Security Element: enclosing informationUsernameToken blockDefines how username-and-password info is enclosed in SOAPEnd users: SAML Authentication Assertion or Kerberos ticket, shared uname/pwd secretPassword 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 TransformDue to mutability of SOAP headerDoes not use the Enveloping SignatureExplicitly 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

    Extensible mechanism that provides an open content model for referencing security tokensNew reference option for XML signatureSTR Deference TransformMeans 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

  • Example of a Token with signature



    ... ...

    Open content model for specifying token. It could be XML, URI, We use the content here using #STR-Transform and compute the digest

  • Extended exampleSOAP EnvelopeSOAP HeaderWS SecuritySecurity token (a certificate)Encryption key (passing symmetric key)SignatureSOAP BodyEncrypted content

  • Overall message structure

    ... ... ... ... ...

  • 1. Binary security token



  • 2. Passing encryption key

    ABCDEF.... ...

    We are using another certificate for asymmetric crypto.Encrypted 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

  • 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

  • A username token in WS-Security SOAP Header

    abc xyzabc ap2oep3oaeap1 ... ...

  • A Binary X.509 Certificate in WS-Security SOAP header

    ABCDEF.. ... ... ...

  • A SAML Assertion in WS-Security SOAP Header

    ... ... ... SecurityToken-123 ...

    SAML does not allow the use of the ID attribute with assertion elements, hence AssertionIDReference is used

  • 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 2.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-AttachmentsSupports signing/encrypting message elements and policiesMore information and downloads

  • Lecture SummarySecurity contextsSecurity needed within and between contextsXML validation, encryption, and authentication needed between security contexts!WS security standard revisitedSOAP header carries security information (and other info as well)Selective processingSAMLStatements about authorization, authentication, attributesSAML & WS-Security & XACMLImplementations available