Posts Tagged 'web services'

Axis2 Based Web Services Application Server, WSAS 2.2 released

The WSO2 WSAS team is pleased to announce the release of the WSO2 WSAS 2.2. WSO2 WSAS is an enterprise ready Web services engine powered by Apache Axis2 release under the Apache Software License 2.0.

This release can be downloaded from http://wso2.org/projects/wsas/java

Maven2 binary distribution download
– Group Id : org.wso2.wsas
– Artifact Id : wso2wsas
– Version : 2.2
– Type : zip
– WSO2 Maven2 Repository URL : http://dist.wso2.org/maven2/

Maven2 source distribution download
– Group Id : org.wso2.wsas
– Artifact Id : wso2wsas
– Version : 2.2
– Type : zip
– Classifier : src
– WSO2 Maven2 Repository URL : http://dist.wso2.org/maven2/

From the WSO2 WSAS 2.2 – Release Note – 22nd Jan 2008
=====================================================

WSO2 WSAS is an enterprise ready Web services engine powered by Apache Axis2 and which offers a complete middleware solution. It is a lightweight, high performing platform for Service Oriented Architectures, enabling business logic and applications.
Bringing together a number of Apache Web services projects, WSO2 WSAS provides a secure, transactional and reliable runtime for deploying and managing Web services.

Key Features
————
* Data services support – Expose you enterprise data as a services in a jiffy
* WSAS IDE – Eclipse IDE integration
* Clustering support for High Availability & High Scalability
* Full support for WS-Security, WS-Trust, WS-Policy and WS-Secure Conversation and XKMS
* EJB service provider support – Expose your EJBs as services
* Axis1 backward compatibility – Deploy Axis1 services on WSAS & Engage advanced WS-* protocols in front of legacy services
* JMX & Web interface based monitoring and management
* WS-* & REST support
* GUI, command line & IDE based tools for Web service development

New Features In This Release
—————————-
* Improved Data Services support including New & improved UI, and database connection pooling
* WS-Security 1.1 support
* Improved clustering support
* Improved JSR-181 & JAXWS support
* JMX based monitoring
* Graceful shutdown & restart of the server
Serve all pending requests before shutting down or restarting the server
* Improvements to the Management Console
* Various bug fixes to Apache Axis2, Apache Rampart & WSAS

Data Services – Bringing Enterprise Data to Web
———————————————–
* Service enable data locked in relational databases, CSV & Excel files in no time
* Zero code. Simple descriptor file describes the data to service mapping
* Controlled access to your data
* Customizable XML output
* Benefit from REST & WS-* support
* Built-in Connection pooling support
* Supports exposing Stored procedures & functions
* Built-in caching
* Throttling – to ensure your database is never overloaded.
* Easy configuration via graphical console
* Test your services via Try-it tool

Training
——–

WSO2 Inc. offers a variety of professional Training Programs, including
training on general Web services as well as WSO2 WSAS, Apache Axis2, Data Services
and a number of other products.

For additional support information please refer to
http://wso2.com/training/course-catalog/

Support
——-

WSO2 Inc. offers a variety of development and production support
programs, ranging from Web-based support up through normal business
hours, to premium 24×7 phone support.

For additional support information please refer to http://wso2.com/support/

For more information on WSO2 WSAS, visit the WSO2 Oxygen Tank (http://wso2.org)

How to do various things with WSAS – WSAS HOWTO Series(http://wso2.org/library/2707)

For further information see the full release note http://wso2.org/project/wsas/java/2.2/docs/release_notes.html

Thanks for your interest in WSO2 WSAS
— WSO2 WSAS Team

Advertisements

WS – Security Policy

Web services security policy language defines a way to express constraints and requirements of a soap message to provide security. These constraints and requirements are defined as policy assertions and these assertions define how messages are secured. These assertions can be categorized in to

  • Security binding assertions
  • Protection assertions
  • Token assertions
  • Supporting token assertions
  • WSS : Soap message security assertions
  • WS – Trust assertions

Security Binding Assertions

Security binding assertions defines main security mechanism used to secure the messages. This assertion defines some properties and these properties define how messages are secured. These also defines which tokens should be used to secure messages using Token assertions. There are 3 security binding assertions, Transport binding, Symmetric binding and Asymmetric binding. If transport binding is used, message protection is provided by means other than SOAP message security. For example, Transport biding can use HTTPS transport to secure the message between the client and the server. If we use Asymmetric binding assertion, we can easily make both the client and server authenticate them selves using the security tokens defined in this policy assertion. Under this assertion we can specify two requirements with initiator token assertion and recipient token assertion. These assertions defines what type of token should be used by initiator and recipient. When Symmetric binding is used , first encrypted key is derived using the recipients security token , defined in the either encryption token assertion or protection token assertion. Then this encrypted key is used to secure the message back and forth between the recipient and the initiator. This binding facilitates the need to secure the messages between anonymous clients and the server. Only the server has to posses a security token.

Security Binding Properties

Security biding assertions contain some properties which defines how messages are secured.

  • Algorithm Suite – this property defines a algorithmic suite to be used with cryptographic operations. So it is very easy to define all the algorithms using one property. What are the available algorithmic suites and which algorithms are used in those suites can be found in the WS – Security Policy specification.
  • Timestamp – defines whether timestamp should be included in the message
  • Protection Order – when we have to do both signature and encryption, this defines whether to sign then encrypt or encrypt then sign.
  • Signature Protection – defines whether signature should be encrypted. Signature confirmation elements also will be encrypted.
  • Token protection – defines whether signature should cover the security token which used to generate the signature
  • Entire Header and Body Signatures – defines whether signatures should cover only the entire body and entire header elements and not the descendant of elements.
  • Security Header Layout – defines layout rules which applies to security header

Protection Assertions

These assertions defined what message parts are protected and how they are protected. There are mainly two types of protection token assertions. Integrity Assertions and Confidentiality Assertions. Integrity assertions define what elements of the message should be signed and confidentiality assertions defines what elements should be encrypted. Four protections assertions are

  • Signed Parts Assertion – defines whether body should be signed and what soap header elements should be signed
  • Signed Elements Assertion – defines arbitrary elements to be signed using XPath
  • Encrypted Parts Assertion – defines whether body should be signed and what soap header elements should be encrypted
  • Encrypted Elements Assertion – defines arbitrary elements to be encrypted using XPath

Token Assertions

These assertions specify the type of the tokens to be used to protect the messages. These assertions also define two important properties about the tokens used to protect the message.

  • Token Inclusion – defines when to include the binary tokens in the message
  • Derived Keys – defines whether derived keys should be used

some of the token types defined in the WS – Security Policy specification are,

  • Username Tokens
  • X509 Tokens
  • Issued Tokens
  • Secure Conversation Tokens
  • SAML Tokens
  • Https Tokens

Supporting Token Assertions

These tokens defines additional tokens to augment the claims provide by the token which is used to generate the message signature. There are four types of supporting tokens.

  • Supporting Tokens – additional tokens to included in the security header
  • Singed Supporting Tokens – additional tokens to be included in the security header which are also covered by the message signature
  • Endorsing Supporting Tokens – These tokens sign the message signature ( entire ds:Signature element ). So we get an additional signature element which is the signature of the original message signature.
  • Signed Endorsing Supporting Tokens – Here the supporting token is covered by the message signature. And the message signature again is signed using the supporting token.

WSS – SOAP Message Security Options

These options defines the requirements that the initiator and the recipient must support. There are two assertions , Wss10 assertion and Wss11 assertion which defines these requirements.

Wss10 Assertion

  • Direct References – defines whether initiator and recipient must be able to process direct reference
  • Key Identifier References – defines whether initiator and recipient must be able to process key identifier references
  • Issuer Serial References – defines whether initiator and recipient must be able to process issuer serial references
  • External URI References – defines whether initiator and recipient must be able to process external URI references
  • Embedded Token References – defines whether initiator and recipient must be able to process embedded token references

Wss11 Assertion

  • Thumbprint References – defines whether initiator and recipient must be able to process thumbprint references
  • EncryptedKey References – defines whether initiator and recipient must be able to process encrypted key references
  • Signature Confirmation – defines whether signature confirmation as defined in SOAP Message Security 1.1 specification

WS – Trust Assertions

This assertion defines the requirements for exchanges based on WS-Trust, specifically with client and server challenges and entropy behaviors.