Posts Tagged ‘Web services’

Security Assertion Markup Language (SAML)

17 June 2010

Following Web services notion of inter-operating between different disparate systems, SAML supported the idea of making disparate security systems inter-operate with each other.

SAML merged the following parallel security efforts into a single technology and was submitted to Organisation for the Advancement of Structured Information Standards (OASIS):

  1. Security Services Markup Language (S2ML)
  2. Authentication Markup Language (AuthML)

SAML addresses the main problem with cross-domain sharing of security information which are mostly proprietary and required to be tightly coupled with each other.

Main features:

  1. Development of federated systems
  2. Enable seamless integration
  3. Exchange of information among different security systems
  4. Backoffice Transaction
  5. Single-Sign-On (SSO) – user’s ability to authenticate in one security domain and to use the protected resources of another security domain without re-authenticating
  6. XML-based framework for security-related information over Internet

SAML specification consists of the following set of documents:

  1. Assertions and protocol – defines the syntax and semantics for XML-encoded SAML assertions, protocol requests, and protocol responses.
  2. Binding and profiles – defines the frameworks for embedding and transporting SAML assertion requests and responses.
  3. Security and privacy considerations – to provide information to implementers of SAML systems about possible threats, and security risks to which a SAML-based system is subjected.
  4. Conformance program specification – defines a SAML conformance system that isaimed toward achieving compatibility and interoperability among all applications that implement SAML.

SAML Architecture

  1. XML-based frameworks for exchanging security information in the form of an assertion or facts about subjects.
  2. A subject has an identity in some security domain. This subject can be an identified person or it can be some code in which assertion may be required so that the code can be allowed to execute on a system.
  3. A SAML authority or an issuing authority issues the assertions.
  4. The SAML authority can be performed by the following parties:- 3rd party security providers such as Microsoft with Passport- Individual businesses as security provider within Federations such as AMEX, VISA
  5. Three types of core assertions:- authentication assertion- authorisation assertion- attribute assertion
  6. Assertions can be digitally signed using XML Signature as specified by the SAML profile of XML Digital Signature.
  7. Elements of all assertions:– Issuer and Issuance timestamp- Assertion ID– Subject such as name and security domain which the subject belongs to

    – Advice – additional information that the issuing authority may wish to provide to the relying party in regards to how the assertion was made eg. evidence or proof of assertion claims.

    – Conditions – optional element as its validity id dependent upon the evaluation of the conditions provided. Conditions can be as follows:

      + Validity period within which the assertion remain valid after which the assertion would expire
      + Audience restrictions information, which includes relying parties to whom the issuer of this assertion is liable in terms of accuracy or trustworthiness
      + Target restrictions information, which includes targeting relying parties for which the authority has issued this assertion. If consuming party is not the target party then assertion must be rejected.


Advertisements

ESB Features and Benefits

16 June 2010
  1. Web Services Support
    SOAP, WSDL, POX (Plain Old XML) over HTTP
    Design-time tool to create proxy WSDL to a Web service expose by the ESB
    – Supports REST to invoke endpoint URI with XML messages
  2. Adapter
    – Not directly having SOAP or XML interface
    – Adapters to allow integration specifically with different third party applications or systems
  3. Invocation
    – Supports synchronous and asynchronous calls to services or callbacks
  4. Mediation and Protocol Independence
    – Variety of protocols can be reconciled for complex routes across variety of platforms, maintaining loose-coupling between indirectly connected components
    – example SOAP —-> JMS (via HTTP)
    – Allows to plot different protocols on message path besides HTTP and JMS like HTTPS, SMTP, XMPP, FTP etc
    – HL7, EDI… support
  5. Routing
    – Service look-up with registry or repository to perform dynamic routing
    – content-based, rule-based and policy-based routings
    – example of content-based routing, use XPath to select  data from SOAP envelope and on content select new service destination for current message
    – Some ESB provides service-pooling for dynamic routing of messages to another service instance in the pool
  6. Transformation
    – Using XSLT and queried with XQuery and XPath
    – Enhance content of messages to prepare for downstream invocation of other systems
    – Useful for Canonical Data Model
  7. Orchestration
    – To coordinate multiple services to expose them as a single proxy service
    – BPEL or XPDL engine
  8. Security
    – Security policies with policy enforcement points such as SSL and SAML (Security Assertion Markup Language)
  9. Benefits
    – Reduced time to integrate new and existing applications
    – Increased flexibility as system dependencies are reduced. Applications don’t have to know as much about each other, making it easier to change system interfaces or switch them out
    – Simultaneous centralised management of the service catalogue while services are distributed
    – Because of the centralised management capability, buses can collect service metrics in conjunction with Business Activity Monitoring (BAM) in tracking service-level agreements (SLAs) via JMX
    – Use of industry standard interfaces, reducing total cost of ownership
    – Greater agility and responsiveness to change
    – More accurate and up-to-date information via logical centralisation of data management with a single version of the truth
  10. Relevant Integration Patterns
    – Message Bus
    – Content-based Router
    – Pipes and Filters
    – Point-to-Point Channel
    – Normaliser
    – Canonical Data Model

UDDI: The Green, White and Yellow!

22 March 2010

Unlike WSDL and SOAP which are mandatory for Web services, registration of Web services instances in UDDI registries is optional and now falls with the WS-I Basic Profile 1.1.

See:

http://www.ws-i.org/Profiles/BasicProfile-1.1.html#discovery

UDDI provides programmatic interfaces into service registry repositories. This enables us to build programs and services capable of issuing dynamic discovery queries. The result is an automated process called runtime discovery.

See:

http://www.soaspecs.com/uddi.php

Thus, not to worry too much into the intricacies of UDDI as most ESB solution does provide mechanisms and toolset for service registry, discovery and invocation.