Archive for the ‘IT’ Category

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.


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

SOA – Agile Approach

30 March 2010

The agile strategy

The challenge remains to find an acceptable balance between incorporating service-oriented design principles into business analysis environments without having to wait before integrating Web services technologies into technical environments. For many organizations it is therefore useful to view these two approaches as extremes and to find a suitable middle ground.

This is possible by defining a new process that allows for the business-level analysis to occur concurrently with service design and development. Also known as the meet-in-the-middle approach, the agile strategy is more complex than the previous two simply because it needs to fulfill two opposing sets of requirements.

Process

The process steps shown in figure below demonstrate an example of how an agile strategy can be used to reach the respective goals of the top-down and bottom-up approaches.

Figure A sample agile strategy process.

Step 1: Begin the top-down analysis, focusing first on key parts of the ontology and related business entities

The standard top-down analysis begins but with a narrower focus. The parts of the business models directly related to the business logic being automated receive immediate priority.

Step 2: When the top-down analysis has sufficiently progressed, perform service-oriented analysis

While Step 1 is still in progress, this step initiates a service-oriented analysis phase. Depending on the magnitude of analysis required to complete Step 1, it is advisable to give that step a good head start. The further along it progresses, the more service designs will benefit.

After the top-down analysis has sufficiently progressed, model business services to best represent the business model with whatever analysis results are available. This is a key decision point in this process. It may require an educated judgment call to determine whether the on-going top-down analysis is sufficiently mature to proceed with the creation of business service models. This consideration must then be weighed against the importance and urgency of pending project requirements.

Step 3: Perform service-oriented design

The chosen service layers are defined, and individual services are designed as part of a service-oriented design process.

Steps 4, 5, and 6: Develop, test, and deploy the services

Develop the services and submit them to the standard testing and deployment procedures.

Step 7: As the top-down analysis continues to progress, revisit business services

Perform periodic reviews of all business services to compare their design against the current state of the business models. Make a note of discrepancies and schedule a redesign for those services most out of alignment. This typically will require an extension to an existing service for it to better provide the full range of required capabilities. When redesigned, a service will need to again undergo standard development, testing, and deployment steps.

To preserve the integrity of services produced by this approach, the concept of immutable service contracts needs to be strictly enforced. After a contract is published, it cannot be altered. Unless revisions to services result in extensions that impose no restrictions on an existing contract (such as the addition of new operations to a WSDL definition), Step 7 of this process likely will result in the need to publish new contract versions and the requirement for a version management system.

Pros and cons

This strategy takes the best of both worlds (Top-down and Bottom-up) and combines it into an approach for realizing SOA that meets immediate requirements without jeopardizing the integrity of an organization’s business model and the service-oriented qualities of the architecture.

While it fulfills both short and long-term needs, the net result of employing this strategy is increased effort associated with the delivery of every service. The fact that services may need to be revisited, redesigned, redeveloped, and redeployed will add up proportionally to the amount of services subjected to this re-tasking step.

Additionally, this approach imposes maintenance tasks that are required to ensure that existing services are actually kept in alignment with revised business models. Even with a maintenance process in place, services still run the risk of misalignment with a constantly changing business 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.