Posted
almost 3 years
ago
by
nore...@blogger.com (Prabath)
Asanka will be doing a training on the $subject in few hours time.
This session will provide in-depth knowledge on how to implement an SOA solution using the basic elements in an SOA infrastructure. There will be several enterprise SOA
... [More]
patterns mapped to real world and hypothetical business requirements. Implementation details will be practically explained using the WSO2 SOA platform.
If you are yet to register - still its's open - further details here. [Less]
Posted
almost 3 years
ago
by
nore...@blogger.com (Supun Kamburugamuva)
A Component based platform for SOA based on Apache Axis2 Do you believe in software componentization? For the last few decades there were many attempts by different organizations to build component based software systems. They achieved some
... [More]
successes. These attempts lead us to think weather true componentization is a reality? Here is a brief definition of a component.
Component Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:
Multiple-use Non-context-specific Compassable with other components Encapsulated i.e., non-investigable through its interfaces A unit of independent deployment and versioning Now lets look at what is Carbon.
WSO2 Carbon WSO2 Carbon is a SOA platform. Gradually it is evolving by addressing all the parts of a complete SOA platform. This platform is built around the popular web services engine Apache Axis2. Carbon offers a SOA runtime along with a rich set of configuration options. Carbon has a built in Registry which can be used by components running on top of Carbon. Registry acts as a configuration store. Apart from configuration Carbon supports monitoring as well.
At the runtime, when a request is given to a carbon based product (WSAS, ESB, BPS), the system virtually becomes an Axis2 runtime.
Axis2 Component architecture Axis2 is a web service engine. Axis2 is developed to publish and consume web services. Axis2 can be extended to do various things using its modular architecture. For example in Synapse Axis2 is used as the core of an ESB. In Apache ODE, Axis2 is used for a BPL engine. In WSAS, Axis2 is used in it’s true nature i.e. deploying web services. So Axis2 has become a platform for various aspects of SOA. There are various method to extend Axis2 i.e. modules, transports, services. So Axis2 component architecture is very rich.
But can we use pure Axis2 as a platform for various aspects that I have mentioned in a unified manner? Answer is NO!. The drawback lies with the Java modularization and versioning. Lets say, Synapse depends on the external jar X with 1.1 version. ODE is also using this X jar but it depends on the version 1.2. Now we want to build a platform. The moment you put both these jars in to the class path, it is up to the Java virtual machine to pick one of the jar files. This is why pure Axis2 will fail as a platform.
Why OSGI The solution is to use OSGi. Carbon uses OSGI to solve this problem of versioning.
But when you go the OSGi way, everything has to be an OSGi bundle. This is possible within WSO2 products. But for external jar file which doesn’t have a OSGI version, it is bit problematic. The solution is to take these external jars and wrap them in OSGi bundles. This is exactly what has being done in the Carbon Orbit.
Platform Carbon offers a platform. Carbon platform can be considered as two major parts.
1. Runtime Platform
2. Configuration and Monitoring Platform
Carbon runtime platform is an Axis2 instance wrapped in OSGi. Carbon has a web UI framework based on Apache tiles. This UI framework is the front end of the configuration framework. Backend of the configuration is coupled with the Axis2 runtime or Runtime platform.
At the highest level components to runtime platform are components to Axis2. For example Synapse is a runtime component. In order to configure the Synapse runtime component, there are several UI components written on top of the UI platform. All these components are OSGi bundles. Carbon is designed to work in a console and back end mode. In order to achieve this communication between front end configuration framework and backend configuration framework happens using standard web services calls.
Carbon Component As I’ve said earlier there are two types of Components. Runtime Components and Configuration Components are the two types. For all the Configuration components there is a runtime component associated with it. From these two most important part is the Runtime Components. There is no point in having a configuration or monitoring component without anything to configure or monitor.
As I’ve said earlier runtime components are components to Axis2. These runtime components may have different other components. But these components are specific to those parent big components and without the parent component they don’t have an existence. Best example is Synapse Mediators. A mediator is a component of Synapse and Synapse may have lots of them. But Synapse is a component of Axis2.
The componentization offered by Carbon only extend to the componentization provided by Axis2. For example Rampart is the base of security for Carbon. Rampart is designed in a way that it will work with most of the other components of Axis2. This allows a product running in Carbon to easily use Security features provided by Rampart. For example WSAS and ESB both uses this component. WSAS uses security to secure it deployed services. ESB uses the carbon security features directly to secure it’s various components like proxy services. The nice thing about this is ESB and WSAS can use the Configuration UI written for Rampart.
This is same for Reliable Messaging and various transports as well. ESB and WSAS can share both reliable messaging and transport components.
Here is a case where this nice componentization doesn’t work due to the negligence of components developed for Axis2. Axis2 has a clustering implementation which is a component to it. But ODE is not written to use this API. But Synapse is written to use this API. So Carbon can provide clustering to ESB which is based on Synapse but it cannot provide clustering for BPS which is based on ODE.
Project Structure of Carbon Carbon has three logical projects.
Carbon-Orbit
This project wraps non OSGI jars in to OSGI aware jars.
Carbon
This provides the Runtime and Configuration platforms.
Carbon Components
Various Runtime and Configuration components in this project.
A Product A product is a Carbon + Sub set of Carbon Components.
For Example this is how ESB product is built.
ESB uses Axis2 as it’s runtime engine. Synapse is a component to Axis2. There are various carbon components written to configure synapse. Axis2 instance that is used in ESB comes from Carbon platform. Various other features are added using various carbon components like security, reliable messaging etc. Sum of all these things gives a the ESB product.
WSO2 G-Reg If we take WSO2 Carbon as the platform WSO2 Governance Registry is the metadata repository for Carbon. Registry core is built in to the Carbon itself. G-Reg can function as a separate product as well. G-Reg is different from other carbon products because it doesn't offer a runtime as in other products. From the start up of G-Reg to shutdown of G-Reg it is only configuration.
WSAS WSAS provides the functionality host services, secure them apply reliable messaging etc. Clients can talk to these services.
ESB ESB configuration is basically configuring a Synapse instance. It also uses feature like reliable messaging, security etc.
Conclusion This is my personal view of Carbon as a platform. You may have different views. You are welcome to share those ideas.. [Less]
Posted
almost 3 years
ago
by
nore...@blogger.com (Prabath)
This blog post explains how to write policies in XACML for WSO2 Identity Server.
A given policy has an identifier, a rule combining algorithm, a description, a target and a set of rules.
<Policy
... [More]
PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy.</Description>
<Target>...</Target>
<Rule>...</Rule>
</Policy>
Since, a given Policy may contain multiple Rules, each of which may evaluate to different access control decisions, XACML needs some way of reconciling the decisions each makes.
This is done through a collection of Combining Algorithms.
Each algorithm represents a different way of combining multiple descisions evaluated through different rules into a single descision.
Following rule combining algorithms are defined in XACML 2.0.
urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides
urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides
urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable
urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-denyoverrides
urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-permitoverrides
when we have urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable as the rule combining alogorithm, it will pick the first rule applicable from the defined set of Rules.
Once a XACML request being received at the PDP it needs to find a policy that applies to the corresponding request.
To do this, XACML uses the element Target.
A Target is basically a set of simplified conditions for the Subject, Resource and Action that must be met for a Policy or Rule to apply to a given request.
Once a Target is defined directly under Policy element - it defines the set of conditions that must be met to pick that Policy.
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy.</Description>
<Target>
<Subjects>...</Subjects>
<Resources>...</Resources>
<Actions>...</Actions>
</Target>
<Rule>...</Rule>
</Policy>
To make this very clear - let's go through an example.
This policy will be picked for a request having, any Subject, any Action on Resource http://localhost:8280/services/echo/.
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy.</Description>
<Target>
<Subjects> <AnySubject/> </Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/echo/</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions> <AnyAction/> </Actions>
</Target>
<Rule>...</Rule>
</Policy>
For the time being, let's not worry too much about <Resources/> element.
Let's see another example. Here the Target is applied to the Rule - not to the entire Policy it self.
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy.</Description>
<Rule Effect="Permit" RuleId="primary-access-rule">
<Target>
<Subjects> <AnySubject/> </Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/echo/</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions> <AnyAction/> </Actions>
</Target>
</Rule>
</Policy>
I guess, that explains enough about <Policy/> and <Target/> elements.
Let's move to the <Rule/> element. You may recall, that I mentioned there can be multiple Rule elements per given Policy.
Also - we discussed about Rule Combining Algorithms.
Let's focus on the child elements of the Rule element.
The way the Sun XACML engine determines whether a rule is applicable to an incoming request is by evaluating the Target and optional Condition (if it exists).
These are ANDed together, and the rule's effect achieved if the ANDed value is TRUE.
You know where Rule element fits in to a XACML policy - for the purpose of explaining, I'll just take out the isolated Rule element only - so keep in mind this is always within <Policy> tags.
<Rule Effect="Permit" RuleId="primary-access-rule">
<Target>...</Target>
<Condition>...</Condition>
</Rule>
A policy contains one or more Rules.
Each rule has a RuleId and an Effect.
An Effect is the intended consequence of a satisfied rule, which can be either "Deny" or "Permit." This means that if the rule is deemed applicable to an incoming service request, and the rule's conditions evaluate to TRUE, then the specified effect should be enforced.
Since we already discussed about the <Target/> element under the context of <Rule/>, we'll skip it here.
Let's focus on the <Condition/> element.
A Condition is a predicate that must be satisfied for a rule to be assigned its effect.
Okay - a Target defines a set of constraints for a Rule. So - what does a Condition do? Let's differentiate Condition from Target.
While Targets are appealing, frame-like expressions, they have a constrained logic which isn't always expressive enough to narrow down whether a policy is applicable to a service request.
Hence, the need for Condition element arises. If either the policy Target or the Rule Target is not able to adequately express a constraint, a Condition can be added to a Rule.
A Condition can only present within a Rule.
If a Condition is intended to be applicable to the entire Policy, the Condition must be repeated in every Rule in that Policy.
Let's go ahead with an example.
We want to restrict users based on their attributes.
Say - for example a given user has an accessList attribute - and we want to restrict access to a given resource based on the accessList.
I'll take an isolated <Condition/> element here...
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator AttributeId="accessList" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">nurses</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">doctors</AttributeValue>
</Apply>
</Apply>
</Condition>
Let's start from the inner most <Apply/> element.
It uses the string-bag function on two attributes.
This bag function wraps a set of possible values for the attribute defined under <SubjectAttributeDesignator/> element. In this case - possible values for the attribute 'accessList' should be either 'nurses' or 'doctors'.
Now, let's look at the outer most <Apply/> element. It uses string-at-least-one-member-of function which will be applied on the results of the inner function.
In other words - final condition says - if you want to access the resource you have to be a member of 'doctors' or 'nurses'.
This will basically conclude the part-1 of this series of blog posts.
In the next blog post I would like to write about Attributes and Attribute Designators. [Less]
Posted
almost 3 years
ago
I've already installed Erlang using yum in Fedora 10. I wanted to install Erlsom and it's available through CEAN. Steps for installing CEAN is explained nicely in the FAQ. Content of my VERSION file,
CEAN Erlang/OTP R12B erts-5.6.5 linux-x86 devel
You can find the version of Erlang installed with yum info erlang. ...
Posted
almost 3 years
ago
by
nore...@blogger.com (Sami)
The SOA Platform 2.0 beta is almost done.
Are you ready to dive into the great platform...?
Tagged as
server soap web web_services mashup webservices middleware wso2 javascript serverside_mashups
Axis2 (Java)
InstantSVC
WSO2 ESB