Fundermentals of Diameter - Intorduction to AAA Protocol

I recently got my hands on in implementing few applications which exchanged information through diameter protocol.Mainly it was done as a POC (Proof of Concept) to illustrate on the ability of making diameter transactions through the WSO2 ESB. So let me share a little bit of my experience with you.

 

AAA Protocol 

Diameter is a  AAA (Authentication,Authorization, Accounting ) protocol used to manage networking resources/services and its usage.

Authentication 

Authentication is the process where the user sends his/her access credentials proving the identity to a Remote Access Server (RAS) that validates it.  The authentication process would validate the user information with different other servers/directories.

Authorization 

The authenticated user will have certain attributes defined in the RAS which explains the QOS (Quality of Service), IP based validations ect :-

Accounting   

The access to the network will be granted to the user through the Network Access Server (NAS). Once the network access is being granted to the user, the RAS will communicate back and forth with the NAS providing the following information,

•   'Start' giving access to a particular user network access

•   'Stop' giving access to the user 

•   Periodically it will exchange information back and forth between, NAS and RAS indicating the status of the current user session, The NAS will trigger an indication to the RAS when it stops the network access to a user session. 

The image below summarizes how AAA protocol is being adapted in a typical network environment. 

                              
Await for my next set of articles, where i would explain the implementation steps in detail as to how diameter can be used in AAA transactions and how WSO2 ESB can be used to connect with diameter servers.   

Drilling Into the ESB - Part 1 (Fundementals, SOA and ESB Applicability)

Well i was a bit quick in my previous post on explaining a bit more of what the ESB does, but better late than never!

So here we go,
 
An ESB could be better validated through pin pointing to its usage when it comes to Service Oriented Architecture (SOA).

SOA is a standard which will allow business applications to be defined in a Modular, Distributed and a loosely coupled fashion. 

Why Settling For SOA ?  

The current industrial systems are complexed, having one function doing it all is not something to be satisfied of. SOA simply provides the ability to componentized business functionality and expose it as services which adheres to well defined service standards. 

In return, it makes the business functionality to be easily maintained, tested and importantly to be reused. 

ESB Applicability  

That was a short introduction to SOA ! 

once the enterprise adopts to the SOA standards, it drives away from relying on a typical monolithic system and becomes more heterogeneous. The clear challenge now is that the systems are now componentized and requires connectivity in-between them. 

Managing SOA without an ESB

I'll eventually discuss the architectural differences between the ESB and the other alternatives. But for now... 

Theoretically speaking is there's no ESB to manage your system.. your whole system might end up becoming a flop !

You could find out why by vising the following website which will take you through a Webinar,

http://wso2.com/library/webinars/2013/05/enterprise-integration-wso2-esb-introduction-fundamentals/





 

 

 

Writing a Mock Service using WSO2 ESB

The following is WSO2 ESB configuration which will allow sending a mock response back to its caller.

<proxy xmlns="http://ws.apache.org/ns/synapse"
      name="testMockService"
      transports="https,http"
      statistics="disable"
      trace="disable"
      startOnLoad="true">
  <target>
     <inSequence>
        <log level="custom">
           <property name="MockService" value="Service Invoked"/>
        </log>
        <log level="full"/>
        <payloadFactory>
           <format>
               <response>
                    <response1>Sample Test Response</response1>
                    <info>http://www.wso2.com</info>
                 </response>
           </format>
           <args/>
        </payloadFactory>
        <header name="To" action="remove"/>
        <property name="RESPONSE" value="true" scope="default" type="STRING"/>
        <property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
        <send/>
     </inSequence>
  </target>
  <description/>
</proxy>

Note the following characteristics of the configuration,


      <payloadFactory>
           <format>
               <response>
                    <response1>Sample Test Response</response1>
                    <info>http://www.wso2.com</info>
                 </response>
           </format>
           <args/>
        </payloadFactory>


The above configuration snippet will allow constructing a new payload which should be sent, the xml elements listed between the <format/> tag will construct the new payload.

Note the following three properties,


        <header name="To" action="remove"/>
        <property name="RESPONSE" value="true" scope="default" type="STRING"/>
        <property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>

The above will allow the message to be set back to be transmitted to the caller who sent the message,

using the <send /> will result in sending the constructed message back to the caller.