Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store
On Mon, Feb 23, 2015 at 4:07 PM, Amila De Silva ami...@wso2.com wrote: Hi Samisa, Should be compatible with IS 5.0. With the SP I suppose? On Mon, Feb 23, 2015 at 3:38 PM, Samisa Abeysinghe sam...@wso2.com wrote: Which WSO2 IS server version will API-M 1.9 support? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Feb 16, 2015 at 4:23 PM, Amila De Silva ami...@wso2.com wrote: Hi All, With API Manager 1.9.0, capability will be provided to plug in an External Authorization server. With this change, Authorization Server will be the only entity creating OAuth clients, and issuing access tokens. In order to seamlessly support some of the existing APIM features, certain changes should be done on the Store: 1. Generating Application Token using an Extended Grant Type As of now, Store UI allows to specify a validity period when Generating an Application Access Token. In the previous releases this was possible, since KeyManager component could directly access the tables where tokens are kept. So after generating a token through UI, Store could update the newly generated token giving a preferred validity period. After decoupling Authorization Server, Store would no longer be able to do this, through a direct DB call. Solution to overcome this problem would be to use an entirely new Grant Type to Generate the Application Access Token. The new Grant type would accept validity period as a new parameter and use it when generating the Application Access Token. 2. Using a Separate Table to store Application Access Tokens Currently, when rendering the UI, Store gets the Access Token by querying the Database directly. After decoupling AS, if we are to Display the Application Token, we would have to Keep the token in a separate Table. In this scenario, Store would act as another client App created on the AS and the Table for storing tokens will be used as a temporary storage. This means that only the most recent Access Token will be kept in, and the table won’t be used to obtain token meta data (such as validity period , Consumer Key) during an API invocation. 3. Generate the token only using /token, /authorize endpoints First time when creating an Application Access Token, Store calls APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. This method, simply creates a token and write it down to IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when moving forward, we would have to obtain the the Application Access Token only using standard OAuth endpoints. 4. Determining the type of a token using a scope In API Manager, the type of the token (whether it is Application or Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. Token Type is used when validating API Invocations (When defining a resource, the type of token required to access it can be specified, and a resource can be only accessed with a token of the specified type). Since the type of the token is tightly coupled with our implementation of Tokens, to make it usable across different Authorization Servers, Token type will be mapped to a scope. So Application Tokens will have a scope like am:application_token (we can make the scope name configurable). When a token is generated through the Store UI, Store will request the token with this scope. These are the major changes required for the Store to function properly. Would appreciate your feedback on these. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg
Senaka, multiple relatioships are fine: it doesn't occur very often, and if, more than two relations are rare. And, yes, by all means, the ability to toggle particular collections of relationship types on and off is extremely helpful! Similarly, the feature that Isabelle brought up, namely specifying the level of children of a certain node to view, will help comprehension... Who will detect policy violations (and: which kind of policies?)? If policy violations are automatically detected, corresponding workflows might be kicked-off to repair the violations. This will significantly contribute to compliance, an key aspect of governance. Best regards, Frank 2015-02-22 20:34 GMT+01:00 Senaka Fernando sen...@wso2.com: Hi Frank, Jerad, Useful thought on colouring relationships. Frank, I have one question. What if multiple relationships coincide between two specific nodes, won't that complicate things? I have a feeling that turning relationships on and off (as in Jerad's GIF) is a way of visualizing how things connect and how deep. WDYT? Also, I have another question. Something I spoke about in WSO2Con US 2013, :), on G-Reg 5.0.0 was that you can use this view to understand lifecycle state, policy violations etc. Didn't see that part being addressed though. Jerad, given the things you've done so far, I don't expect this to be an impossible task, but how easy would it be to annotate nodes (using colours or miniature overlay graphics) to achieve this? Put together, these features alone will make G-Reg 10-times more usable that where it stands today in terms of Asset Governance. Thanks, Senaka. On Sun, Feb 22, 2015 at 5:00 PM, Frank Leymann fr...@wso2.com wrote: HI Jerad, thanks, the gif was helpful :-) Very nice tool! Coloring nodes is optional (I would even argue: not needed). But coloring relations will in fact improve comprehension of the user. See for example when you select in your gif a subset of relationship types: it is still unclear which relationship types connect the nodes. I would rank relationship coloring much higher than node coloring. Best regards, Frank 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com: Hi Frank, I get your point. Agree for giving users more flexible features. Yes, we were discussing about the coloring nodes, and this was decided to have like an optional feature. So it will be an enhance feature for filtering option. Which we decided to work on after releasing the tool. :) Please find the attached animated .gif image, that will give better idea about the tool functions. (Use chrome or better .gif previewer to open - since the file is large, it might not work on all the browsers correctly) Thanks, Jerad -- *Jerad Rutnam* *Software Engineer* WSO2 Inc. lean | enterprise | middleware M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com -- *[image: http://wso2.com] http://wso2.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +44 782 741 1966 %2B44%20782%20741%201966Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store
Yes, there are some SP 1 fixes, on which some KM features depend on. On Mon, Feb 23, 2015 at 4:15 PM, Samisa Abeysinghe sam...@wso2.com wrote: On Mon, Feb 23, 2015 at 4:07 PM, Amila De Silva ami...@wso2.com wrote: Hi Samisa, Should be compatible with IS 5.0. With the SP I suppose? On Mon, Feb 23, 2015 at 3:38 PM, Samisa Abeysinghe sam...@wso2.com wrote: Which WSO2 IS server version will API-M 1.9 support? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Feb 16, 2015 at 4:23 PM, Amila De Silva ami...@wso2.com wrote: Hi All, With API Manager 1.9.0, capability will be provided to plug in an External Authorization server. With this change, Authorization Server will be the only entity creating OAuth clients, and issuing access tokens. In order to seamlessly support some of the existing APIM features, certain changes should be done on the Store: 1. Generating Application Token using an Extended Grant Type As of now, Store UI allows to specify a validity period when Generating an Application Access Token. In the previous releases this was possible, since KeyManager component could directly access the tables where tokens are kept. So after generating a token through UI, Store could update the newly generated token giving a preferred validity period. After decoupling Authorization Server, Store would no longer be able to do this, through a direct DB call. Solution to overcome this problem would be to use an entirely new Grant Type to Generate the Application Access Token. The new Grant type would accept validity period as a new parameter and use it when generating the Application Access Token. 2. Using a Separate Table to store Application Access Tokens Currently, when rendering the UI, Store gets the Access Token by querying the Database directly. After decoupling AS, if we are to Display the Application Token, we would have to Keep the token in a separate Table. In this scenario, Store would act as another client App created on the AS and the Table for storing tokens will be used as a temporary storage. This means that only the most recent Access Token will be kept in, and the table won’t be used to obtain token meta data (such as validity period , Consumer Key) during an API invocation. 3. Generate the token only using /token, /authorize endpoints First time when creating an Application Access Token, Store calls APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. This method, simply creates a token and write it down to IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when moving forward, we would have to obtain the the Application Access Token only using standard OAuth endpoints. 4. Determining the type of a token using a scope In API Manager, the type of the token (whether it is Application or Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. Token Type is used when validating API Invocations (When defining a resource, the type of token required to access it can be specified, and a resource can be only accessed with a token of the specified type). Since the type of the token is tightly coupled with our implementation of Tokens, to make it usable across different Authorization Servers, Token type will be mapped to a scope. So Application Tokens will have a scope like am:application_token (we can make the scope name configurable). When a token is generated through the Store UI, Store will request the token with this scope. These are the major changes required for the Store to function properly. Would appreciate your feedback on these. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proposed ESB connector scenario - Integrating PagerDuty with Gmail, LiveChat, Nexmo, Podio and SurveyGizmo
Hi All, FFI, following methods will be implemented under following connectors: *PagerDuty Connector* createIncident - Create a new event. (Incident is an event with type 'trigger') getIncidentById - Get incident by the ID. listIncidents - List incidents. resolveIncident - Mark an incident as resolved. reassignIncident - Reassign the incident. createNote - Create a note (add a note) for an incident. listNotes - List the notes for an incident. createUser - Create a new user. listUsers - List all the users. getUserById - Get user details by the ID. createContactMethod - Create new contact method for a user. E.g. Phone listContactMethods - List all contact methods for a user. *LiveChat Connector* createTicket - Creates a new ticket. listTickets - Returns all tickets. getTicket - Returns single ticket item for the given TICKET_ID. createAgent - Creates a new agent in your license. listAgents - Returns all LiveChat agents list. getAgent - Return complete details of the agent for the given LOGIN. listChats - Get finished chats and left messages. getChat - Returns single chat item for the given CHAT_ID. sendChatTranscriptByEmail - Send chat transcript to e-mail. createGroup - Creates a new group in your license. listGroups - Returns all created groups. getGroup - Returns group details for the given GROUP_ID. *Podio Connector* createTask - Adding a Task. getTask - Display the Task details. listTasks - List Tasks. assignTask - Assign task to a user. updateTask - Update a Task. completeTask - Mark the task as Complete. incompleteTask - Mark the Task as Incomplete. uploadFile - Upload File. attachFile - Attach File to a object. getFile - Display the File details. createReminder - Create a reminder on a object. getReminder - get the Reminder details. Thanks Regards Rasika -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Proposed-ESB-connector-scenario-Integrating-PagerDuty-with-Gmail-LiveChat-Nexmo-Podio-and-SurveyGizmo-tp112590p112962.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg
Good 3D is hard to achieve ;-) Best regards, Frank 2015-02-23 10:55 GMT+01:00 Isabelle Mauny isabe...@wso2.com: +1 - The relationship path is very important to highlight. Right-click on a node, say Show Relationships , or Show Dependencies - And then center the object and highlight the relationships.. Now, I am going to complicate this, but… This really calls for 3D :D - Let the user rotate graph .. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Sun, Feb 22, 2015 at 6:00 PM, Frank Leymann fr...@wso2.com wrote: HI Jerad, thanks, the gif was helpful :-) Very nice tool! Coloring nodes is optional (I would even argue: not needed). But coloring relations will in fact improve comprehension of the user. See for example when you select in your gif a subset of relationship types: it is still unclear which relationship types connect the nodes. I would rank relationship coloring much higher than node coloring. Best regards, Frank 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com: Hi Frank, I get your point. Agree for giving users more flexible features. Yes, we were discussing about the coloring nodes, and this was decided to have like an optional feature. So it will be an enhance feature for filtering option. Which we decided to work on after releasing the tool. :) Please find the attached animated .gif image, that will give better idea about the tool functions. (Use chrome or better .gif previewer to open - since the file is large, it might not work on all the browsers correctly) Thanks, Jerad -- *Jerad Rutnam* *Software Engineer* WSO2 Inc. lean | enterprise | middleware M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg
Hi Frank, Please find my response inline. On Mon, Feb 23, 2015 at 11:38 AM, Frank Leymann fr...@wso2.com wrote: Senaka, multiple relatioships are fine: it doesn't occur very often, and if, more than two relations are rare. To start with I liked you thought from the beginning, but based on the experience during QSPs, Support Queries etc, people chase after these nitty gritty details, and we often spend most of the time fixing minor details like this. But, if we can handle it in some way (I think Jerad mentioned, you start minimalist and then you can turn colours on and off), I'm perfectly fine with that. And, yes, by all means, the ability to toggle particular collections of relationship types on and off is extremely helpful! Similarly, the feature that Isabelle brought up, namely specifying the level of children of a certain node to view, will help comprehension... Who will detect policy violations (and: which kind of policies?)? If policy violations are automatically detected, corresponding workflows might be kicked-off to repair the violations. This will significantly contribute to compliance, an key aspect of governance. Let me give you some examples of what I meant by Policy Violations. When you upload WSDL/WADL we automatically validate them againts WS-I, WSDL (i.e. standards compliance), and optionally a user can establish their own namespace checks, operation name validations etc. A standard property (or perhaps, quasi-standard to be precise) captures the valid/invalid state. We also can check whether a service exposes the kind of security you'd want it to, and also other similar kinds of policies. These again are recorded against the service as metadata. Another whole area is the lifecycle state, development vs QA vs prod. These again are standard properties. My view here was to annotate each of the nodes based on these properties such that they can be visualized as such in an impact graph, which will add a lot of meaning of what we see today. WRT compliance, I believe that's a separate thing, and I agree with you on its significance. We do have the capability to enforce compliance checks and also invoke external systems on failure as a part of the lifecycle management functionality. This is not fully automated though. But, the product does allow you to schedule tasks which can be utilised to achieve some level of automation. So, we do have a framework where we can start, but few things to be done and interfaces to be introduced for this to be useful. I believe that this is surely beyond 5.0.0. Thanks, Senaka. Best regards, Frank 2015-02-22 20:34 GMT+01:00 Senaka Fernando sen...@wso2.com: Hi Frank, Jerad, Useful thought on colouring relationships. Frank, I have one question. What if multiple relationships coincide between two specific nodes, won't that complicate things? I have a feeling that turning relationships on and off (as in Jerad's GIF) is a way of visualizing how things connect and how deep. WDYT? Also, I have another question. Something I spoke about in WSO2Con US 2013, :), on G-Reg 5.0.0 was that you can use this view to understand lifecycle state, policy violations etc. Didn't see that part being addressed though. Jerad, given the things you've done so far, I don't expect this to be an impossible task, but how easy would it be to annotate nodes (using colours or miniature overlay graphics) to achieve this? Put together, these features alone will make G-Reg 10-times more usable that where it stands today in terms of Asset Governance. Thanks, Senaka. On Sun, Feb 22, 2015 at 5:00 PM, Frank Leymann fr...@wso2.com wrote: HI Jerad, thanks, the gif was helpful :-) Very nice tool! Coloring nodes is optional (I would even argue: not needed). But coloring relations will in fact improve comprehension of the user. See for example when you select in your gif a subset of relationship types: it is still unclear which relationship types connect the nodes. I would rank relationship coloring much higher than node coloring. Best regards, Frank 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com: Hi Frank, I get your point. Agree for giving users more flexible features. Yes, we were discussing about the coloring nodes, and this was decided to have like an optional feature. So it will be an enhance feature for filtering option. Which we decided to work on after releasing the tool. :) Please find the attached animated .gif image, that will give better idea about the tool functions. (Use chrome or better .gif previewer to open - since the file is large, it might not work on all the browsers correctly) Thanks, Jerad -- *Jerad Rutnam* *Software Engineer* WSO2 Inc. lean | enterprise | middleware M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com -- *[image: http://wso2.com] http://wso2.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation;
Re: [Architecture] [APIM] Decoupling Authorization Server - Authenticating with Identity Server from API Store
On Mon, Feb 23, 2015 at 5:43 PM, Ranga Siriwardena ra...@wso2.com wrote: Hi All, During the API Manager Key Manager separation, we identified that we will need to authenticate to identity components as signed in user instead of admin user which is pre-configured in api-manager configuration. For example, Lets say we have two users called subscriber1 and subscriber2. When creating OAuth Applications we have to call Oauth Admin Service as particular user so that, this user can retrieve his/her applications only. For this purpose we are facing two issues. 1) User has to sign in to Identity side admin services with basic authentication (using username and password). But password is not available in API store for this requirement. 2) User has to have permissions defined for particular admin service. In this case user need to have /permission/admin/manage permission to access OAuth Admin Service. As a solution for the first issue we can use mutual-auth, so that identity server(Key Manager) can trust API store when accessing admin services. How does mutul-auth solve this problem? Say 'ranga' logs into the Store, how does the Store ask the admin service to fetch ranga's OAuth apps only? For the second problem, one option we identified is changing permission required for OAuth Admin Service. So from API Manager side we can give that required permission to API store users (users who has subscriber role). For this we will need to patch IS component to achieve this requirement. Please let us know if you have any concerns/thoughts about this. Thank You. Ranga. -- Ranga Siriwardena Software Engineer WSO2 Inc. -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Server - Authenticating with Identity Server from API Store
With mutual-auth, authentication happens for particular user and user name is send as a header for authentication. If the client is trusted and the user is a valid user, then that user is identified as the signed in user. Thank You. Ranga. On Mon, Feb 23, 2015 at 5:52 PM, Nuwan Dias nuw...@wso2.com wrote: On Mon, Feb 23, 2015 at 5:43 PM, Ranga Siriwardena ra...@wso2.com wrote: Hi All, During the API Manager Key Manager separation, we identified that we will need to authenticate to identity components as signed in user instead of admin user which is pre-configured in api-manager configuration. For example, Lets say we have two users called subscriber1 and subscriber2. When creating OAuth Applications we have to call Oauth Admin Service as particular user so that, this user can retrieve his/her applications only. For this purpose we are facing two issues. 1) User has to sign in to Identity side admin services with basic authentication (using username and password). But password is not available in API store for this requirement. 2) User has to have permissions defined for particular admin service. In this case user need to have /permission/admin/manage permission to access OAuth Admin Service. As a solution for the first issue we can use mutual-auth, so that identity server(Key Manager) can trust API store when accessing admin services. How does mutul-auth solve this problem? Say 'ranga' logs into the Store, how does the Store ask the admin service to fetch ranga's OAuth apps only? For the second problem, one option we identified is changing permission required for OAuth Admin Service. So from API Manager side we can give that required permission to API store users (users who has subscriber role). For this we will need to patch IS component to achieve this requirement. Please let us know if you have any concerns/thoughts about this. Thank You. Ranga. -- Ranga Siriwardena Software Engineer WSO2 Inc. -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 -- Ranga Siriwardena Software Engineer Mobile: +94779808031 WSO2 Inc. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Server - Authenticating with Identity Server from API Store
Actually in mutual authenticator we check for the certificate in the header, which will set if only mutual auth is successful. So idea here is since server trust the client, we trust the user. BTW, mutual authenticator have problems with AWS elb. So this won't be able to use in such places. So in AF we went for signed jwt authenticator due to this issue. On Feb 23, 2015 6:00 PM, Ranga Siriwardena ra...@wso2.com wrote: With mutual-auth, authentication happens for particular user and user name is send as a header for authentication. If the client is trusted and the user is a valid user, then that user is identified as the signed in user. Thank You. Ranga. On Mon, Feb 23, 2015 at 5:52 PM, Nuwan Dias nuw...@wso2.com wrote: On Mon, Feb 23, 2015 at 5:43 PM, Ranga Siriwardena ra...@wso2.com wrote: Hi All, During the API Manager Key Manager separation, we identified that we will need to authenticate to identity components as signed in user instead of admin user which is pre-configured in api-manager configuration. For example, Lets say we have two users called subscriber1 and subscriber2. When creating OAuth Applications we have to call Oauth Admin Service as particular user so that, this user can retrieve his/her applications only. For this purpose we are facing two issues. 1) User has to sign in to Identity side admin services with basic authentication (using username and password). But password is not available in API store for this requirement. 2) User has to have permissions defined for particular admin service. In this case user need to have /permission/admin/manage permission to access OAuth Admin Service. As a solution for the first issue we can use mutual-auth, so that identity server(Key Manager) can trust API store when accessing admin services. How does mutul-auth solve this problem? Say 'ranga' logs into the Store, how does the Store ask the admin service to fetch ranga's OAuth apps only? For the second problem, one option we identified is changing permission required for OAuth Admin Service. So from API Manager side we can give that required permission to API store users (users who has subscriber role). For this we will need to patch IS component to achieve this requirement. Please let us know if you have any concerns/thoughts about this. Thank You. Ranga. -- Ranga Siriwardena Software Engineer WSO2 Inc. -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 -- Ranga Siriwardena Software Engineer Mobile: +94779808031 WSO2 Inc. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store
Hi Samisa, Should be compatible with IS 5.0. On Mon, Feb 23, 2015 at 3:38 PM, Samisa Abeysinghe sam...@wso2.com wrote: Which WSO2 IS server version will API-M 1.9 support? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Feb 16, 2015 at 4:23 PM, Amila De Silva ami...@wso2.com wrote: Hi All, With API Manager 1.9.0, capability will be provided to plug in an External Authorization server. With this change, Authorization Server will be the only entity creating OAuth clients, and issuing access tokens. In order to seamlessly support some of the existing APIM features, certain changes should be done on the Store: 1. Generating Application Token using an Extended Grant Type As of now, Store UI allows to specify a validity period when Generating an Application Access Token. In the previous releases this was possible, since KeyManager component could directly access the tables where tokens are kept. So after generating a token through UI, Store could update the newly generated token giving a preferred validity period. After decoupling Authorization Server, Store would no longer be able to do this, through a direct DB call. Solution to overcome this problem would be to use an entirely new Grant Type to Generate the Application Access Token. The new Grant type would accept validity period as a new parameter and use it when generating the Application Access Token. 2. Using a Separate Table to store Application Access Tokens Currently, when rendering the UI, Store gets the Access Token by querying the Database directly. After decoupling AS, if we are to Display the Application Token, we would have to Keep the token in a separate Table. In this scenario, Store would act as another client App created on the AS and the Table for storing tokens will be used as a temporary storage. This means that only the most recent Access Token will be kept in, and the table won’t be used to obtain token meta data (such as validity period , Consumer Key) during an API invocation. 3. Generate the token only using /token, /authorize endpoints First time when creating an Application Access Token, Store calls APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. This method, simply creates a token and write it down to IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when moving forward, we would have to obtain the the Application Access Token only using standard OAuth endpoints. 4. Determining the type of a token using a scope In API Manager, the type of the token (whether it is Application or Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. Token Type is used when validating API Invocations (When defining a resource, the type of token required to access it can be specified, and a resource can be only accessed with a token of the specified type). Since the type of the token is tightly coupled with our implementation of Tokens, to make it usable across different Authorization Servers, Token type will be mapped to a scope. So Application Tokens will have a scope like am:application_token (we can make the scope name configurable). When a token is generated through the Store UI, Store will request the token with this scope. These are the major changes required for the Store to function properly. Would appreciate your feedback on these. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Server - Authenticating with Identity Server from API Store
I don't think using SAML is a viable option because API Manager should work without configuring SAMLSSO. For example, currently you can login to Store with direct username/password authentication from the userstore connected to AM. If we are opting for SAMLSSO, then that means either depending on a SAML IdP or having SAML components inside AM. On Tue, Feb 24, 2015 at 1:40 AM, Manuranga Perera m...@wso2.com wrote: Hi Ranga/Dulanja, (for 1) can't we do this by sending the SAML assertion form API store to IS side -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : m...@wso2.com -- Dulanja Liyanage WSO2 Inc. M: +94776764717 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Server - Authenticating with Identity Server from API Store
Hi Ranga/Dulanja, (for 1) can't we do this by sending the SAML assertion form API store to IS side -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : m...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev][ES] What is the strategy of maintaining versions in REST APIs
Hi Cyril, The reason for having 'v' symbolic link (in http://localhost:9763/publisher/apis/v/assets?type=gadget ) to access latest API, is to have a consistency across all the places where REST API endpoints are used. For example, in places where URL pattern matchers are implemented this consistency of URL pattern is necessary. Thanks! -Ayesha On Wed, Feb 11, 2015 at 6:21 PM, Cyril Rognon cyril.rog...@emoxa.fr wrote: Hi all, Do we really need some v si=ymbolic link to access the latest version ? Could we allow the *http://localhost:9763/publisher/apis/assets?type=gadget http://localhost:9763/publisher/apis/assets?type=gadget* url to point to the latest version ? In the User Stories we encounter we try to practice governance with principles like any new customer have to use the latest version available. It could be simpler if the default version (original url with no version info) would point to this one. Do you have some other User story that would not fit into this scenario ? Cheers, Cyril On Wed, Feb 11, 2015 at 12:36 PM, Ayesha Dissanayaka aye...@wso2.com wrote: Hi all, Currently in ES-2.0.0 milestone releases, REST API endpoints are implemented without a version. ex: *http://localhost:9763/publisher/apis/assets?type=gadget http://localhost:9763/publisher/apis/assets?type=gadget* And we don't track versions in the code base either. If we are to maintain versions in ES REST API, sample endpoint will be like *http://localhost:9763/publisher/apis/v1/assets?type=gadget http://localhost:9763/publisher/apis/v1/assets?type=gadget *where *'v1' *is the relevant REST API version. The latest versions will be served in *http://localhost:9763/publisher/apis/v/assets?type=gadget http://localhost:9763/publisher/apis/v/assets?type=gadget *where *'v' *is a symbolic link to the latest REST APIs. Also we will have to maintain all the existing APIs along with the future releases of ES REST APIs in order to support product migrations and etc. Considering this, do we need to maintain versions in ES REST APIs and what is the wso2 strategy of versioning REST APIs? Thanks! - Ayesha -- *Ayesha Dissanayaka* Software Engineer, WSO2, Inc : http://wso2.com http://www.google.com/url?q=http%3A%2F%2Fwso2.comsa=Dsntz=1usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg 20, Palmgrove Avenue, Colombo 3 E-Mail: aye...@wso2.com ayshsa...@gmail.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ayesha Dissanayaka* Software Engineer, WSO2, Inc : http://wso2.com http://www.google.com/url?q=http%3A%2F%2Fwso2.comsa=Dsntz=1usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg 20, Palmgrove Avenue, Colombo 3 E-Mail: aye...@wso2.com ayshsa...@gmail.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] API Manager 1.9.0 Milestone 1 Released
Hi Samisa, Please find the document link from [1]. We are updating [1] in each milestone.. And IS integration as KM fully testing is depend on completing the feature [2] which is targeted to milestone 2.. [1] https://docs.wso2.com/display/AM190/WSO2+API+Manager+Documentation [2] [Architecture] API Manager Authorization Server Decoupling Thanks; On Sat, Feb 21, 2015 at 1:54 AM, Samisa Abeysinghe sam...@wso2.com wrote: Where can I find the docs for this release? Also, what is the IS version for KM that should be used against this version of API-M? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Fri, Feb 20, 2015 at 8:08 PM, Lalaji Sureshika lal...@wso2.com wrote: *API Manager 1.9.0 Milestone 1 Released!* WSO2 API Manager team is pleased to announce the 1st Milestone release of WSO2 API Manager 1.9.0. The distribution is available to download at [1]. This release includes following features,improvements and bug fixes. Bug - [APIMANAGER-932 https://wso2.org/jira/browse/APIMANAGER-932] - Integration tests for TokenParser should add to api configuration by default. - [APIMANAGER-966 https://wso2.org/jira/browse/APIMANAGER-966] - RESTClient 'Response Headers' section doesn't show additional Header fields (Eg: 'Allow:' Header field that is returned for OPTIONS). - [APIMANAGER-1336 https://wso2.org/jira/browse/APIMANAGER-1336] - Billing Sample data is not accurate and java.lang.ClassCastException thrown when refreshing the page or when no data is available - [APIMANAGER-1387 https://wso2.org/jira/browse/APIMANAGER-1387] - Issues with billing sample - [APIMANAGER-1787 https://wso2.org/jira/browse/APIMANAGER-1787] - [GREG-APIM] StringIndexOutOfBoundsException occurs when launch Endpoint URL of resource in API list - [APIMANAGER-2015 https://wso2.org/jira/browse/APIMANAGER-2015] - Statistics in API Manager gives an error when EnableBillingAndUsage is set to true - [APIMANAGER-2019 https://wso2.org/jira/browse/APIMANAGER-2019] - Input after double quote in the description of an application gets lost - [APIMANAGER-2037 https://wso2.org/jira/browse/APIMANAGER-2037] - When adding an API, and when the API name contains special characters, the API addition fails, but the appeared UI message is not descriptive enough for the user to identify what went wrong. - [APIMANAGER-2087 https://wso2.org/jira/browse/APIMANAGER-2087] - 'Test Endpoint button' says valid for some invalid endpoints - [APIMANAGER-2233 https://wso2.org/jira/browse/APIMANAGER-2233] - Tenant user name format in publisher statistics pages - [APIMANAGER-2704 https://wso2.org/jira/browse/APIMANAGER-2704] - Blocked subscriptions can be unblocked by re-subscribing to an API - [APIMANAGER-2780 https://wso2.org/jira/browse/APIMANAGER-2780] - APIM Test URI functionality in the API implementation section and the Google Analytics Publishing are not proxy aware - [APIMANAGER-2821 https://wso2.org/jira/browse/APIMANAGER-2821] - WorkFlows: Eventhough the subscription pending for approval is deleted from store, it still exists in workflow admin. - [APIMANAGER-2965 https://wso2.org/jira/browse/APIMANAGER-2965] - Application Name showed as null in all store statistics pages when token encryption enabled - [APIMANAGER-3010 https://wso2.org/jira/browse/APIMANAGER-3010] - Issue in displaying the number of APIs displayed in the API Store - [APIMANAGER-3161 https://wso2.org/jira/browse/APIMANAGER-3161] - Endpoints are not shown on the UI when an API is created by invoking the REST API - [APIMANAGER-3204 https://wso2.org/jira/browse/APIMANAGER-3204] - AM1.7-BAM2.4.1 Metering Billing page always shows the rate 0.00 as cost - [APIMANAGER-3206 https://wso2.org/jira/browse/APIMANAGER-3206] - Issue in the Document Summary field - [APIMANAGER-3218 https://wso2.org/jira/browse/APIMANAGER-3218] - fixing stats showing in borwser even when APIUsageTracking is disabled - [APIMANAGER-3219 https://wso2.org/jira/browse/APIMANAGER-3219] - Issue in the API creation Design page Context field - [APIMANAGER-3220 https://wso2.org/jira/browse/APIMANAGER-3220] - In APIM Publisher faulty invocation graph Y-axis do not start with 0 - [APIMANAGER-3225 https://wso2.org/jira/browse/APIMANAGER-3225] - The Popup error message doesn't showing up in the second time when uploading a file name exceeds a certain length - [APIMANAGER-3228 https://wso2.org/jira/browse/APIMANAGER-3228] - First request in tenant erroneously sent to HTTP proxy - [APIMANAGER-3243 https://wso2.org/jira/browse/APIMANAGER-3243] - Workflows: admin-dashboard does not display the Approval Tasks sometimes even without login out - [APIMANAGER-3250 https://wso2.org/jira/browse/APIMANAGER-3250] - My subscriptions
Re: [Architecture] Proposed ESB connector scenario - Integrating PagerDuty with Gmail, LiveChat, Nexmo, Podio and SurveyGizmo
Hi Shevan, We have already put the Gmail related scenarios on hold until the Gmail connector is ready. i.e. *Retrieve selected messages from Gmail API (where the client has reported the incidents) and create an incident in PagerDuty API* will be implemented once the new Gmail connector is implemented. Thanks Regards Rasika -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Proposed-ESB-connector-scenario-Integrating-PagerDuty-with-Gmail-LiveChat-Nexmo-Podio-and-SurveyGizmo-tp112590p112956.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg
+1 - The relationship path is very important to highlight. Right-click on a node, say Show Relationships , or Show Dependencies - And then center the object and highlight the relationships.. Now, I am going to complicate this, but… This really calls for 3D :D - Let the user rotate graph .. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Sun, Feb 22, 2015 at 6:00 PM, Frank Leymann fr...@wso2.com wrote: HI Jerad, thanks, the gif was helpful :-) Very nice tool! Coloring nodes is optional (I would even argue: not needed). But coloring relations will in fact improve comprehension of the user. See for example when you select in your gif a subset of relationship types: it is still unclear which relationship types connect the nodes. I would rank relationship coloring much higher than node coloring. Best regards, Frank 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com: Hi Frank, I get your point. Agree for giving users more flexible features. Yes, we were discussing about the coloring nodes, and this was decided to have like an optional feature. So it will be an enhance feature for filtering option. Which we decided to work on after releasing the tool. :) Please find the attached animated .gif image, that will give better idea about the tool functions. (Use chrome or better .gif previewer to open - since the file is large, it might not work on all the browsers correctly) Thanks, Jerad -- *Jerad Rutnam* *Software Engineer* WSO2 Inc. lean | enterprise | middleware M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store
Which WSO2 IS server version will API-M 1.9 support? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Mon, Feb 16, 2015 at 4:23 PM, Amila De Silva ami...@wso2.com wrote: Hi All, With API Manager 1.9.0, capability will be provided to plug in an External Authorization server. With this change, Authorization Server will be the only entity creating OAuth clients, and issuing access tokens. In order to seamlessly support some of the existing APIM features, certain changes should be done on the Store: 1. Generating Application Token using an Extended Grant Type As of now, Store UI allows to specify a validity period when Generating an Application Access Token. In the previous releases this was possible, since KeyManager component could directly access the tables where tokens are kept. So after generating a token through UI, Store could update the newly generated token giving a preferred validity period. After decoupling Authorization Server, Store would no longer be able to do this, through a direct DB call. Solution to overcome this problem would be to use an entirely new Grant Type to Generate the Application Access Token. The new Grant type would accept validity period as a new parameter and use it when generating the Application Access Token. 2. Using a Separate Table to store Application Access Tokens Currently, when rendering the UI, Store gets the Access Token by querying the Database directly. After decoupling AS, if we are to Display the Application Token, we would have to Keep the token in a separate Table. In this scenario, Store would act as another client App created on the AS and the Table for storing tokens will be used as a temporary storage. This means that only the most recent Access Token will be kept in, and the table won’t be used to obtain token meta data (such as validity period , Consumer Key) during an API invocation. 3. Generate the token only using /token, /authorize endpoints First time when creating an Application Access Token, Store calls APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. This method, simply creates a token and write it down to IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when moving forward, we would have to obtain the the Application Access Token only using standard OAuth endpoints. 4. Determining the type of a token using a scope In API Manager, the type of the token (whether it is Application or Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. Token Type is used when validating API Invocations (When defining a resource, the type of token required to access it can be specified, and a resource can be only accessed with a token of the specified type). Since the type of the token is tightly coupled with our implementation of Tokens, to make it usable across different Authorization Servers, Token type will be mapped to a scope. So Application Tokens will have a scope like am:application_token (we can make the scope name configurable). When a token is generated through the Store UI, Store will request the token with this scope. These are the major changes required for the Store to function properly. Would appreciate your feedback on these. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Serever - Dropping APIKeyMgtSubscriberService
Hi Lasantha, No, that capability will still be there. Plan is to write a custom grant type (similar to client_credentials) which can accept the token validity period as an input parameter. The API Store will invoke the endpoint which implements this grant type. Thanks, NuwanD. On Tue, Feb 24, 2015 at 12:26 AM, Lasantha Fernando lasan...@wso2.com wrote: Hi Amila, Does this mean that there will be no option to set the validity period through UI when renewing an access token? Are we actually breaking the spec if we are changing the access token validity period when renewing a token? Thanks, Lasantha On 23 February 2015 at 11:36, Amila De Silva ami...@wso2.com wrote: Hi All, Until the last APIM release APIKeyMgtSubscriberService was used by API Store to create OAuthApplications, generate/renew Access Tokens. During certain points in generating Application Access Tokens and renewing them, API Store had to access the tables in which OAuth tokens are stored and APIKeyMgtSubscriberService provided a clean interface preventing direct DB calls happening from the API Store. For example, when renewing a token, Store would call renewAccessToken operation, which would call /revoke and /token endpoints to obtain a new token, but which then would directly access IDN_OAUTH2_ACCESS_TOKEN table and change Token Type and validity period provided through Store UI. Plan is to drop APIKeyMgtSubscriberService entirely in the coming release, because 1. Only two of the operations (renewAccessToken getAccessToken) out of all 10 available operations are actually being used. 2. With the changes proposed for Authorization Server Decoupling, all Key Generating operations will be performed through standard endpoints, hence the two operations which access the DB directly will be of no use. Please raise any concerns if this is likely to break anything. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lasantha Fernando* Software Engineer - Data Technologies Team WSO2 Inc. http://wso2.com email: lasan...@wso2.com mobile: (+94) 71 5247551 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Supporting blocking calls in Call mediator
Hi, I am in the progress of implementing the blocking functionality in call mediator. Now the call mediator synapse syntax is changed to cater the above requirement. The synapse configuration for the call mediator blocking functionality (blocking=true) call blocking=true endpoint name=StockQuoteService address uri=http://localhost:9000/services/SimpleStockQuoteService / /endpoint /call The synapse configuration for call mediator default functionality (blocking=false) call blocking=false endpoint name=StockQuoteService address uri=http://localhost:9000/services/SimpleStockQuoteService / /endpoint /call Since the default behavior of the call mediator is non blocking functionality, existing configuration will work as it is. call endpoint name=StockQuoteService address uri=http://localhost:9000/services/SimpleStockQuoteService / /endpoint /call Thanks, Kathees On Mon, Feb 16, 2015 at 4:46 PM, Kathees Rajendram kath...@wso2.com wrote: Hi, We are working on the supporting the blocking functionality in Call mediator. In the Call mediator synapse configuration,We are introducing a new attribute (blocking=true/false). New Syntax for Call mediator: call [blocking=true|false] (endpointref | endpoint)+ /call endpointsref refers to the following, endpoint key=name/ If the blocking is true, Callout mediator blocking functionality will be executed otherwise Call mediator existing functionality will be executed. Thanks, Kathees On Wed, Nov 19, 2014 at 12:07 PM, Srinath Perera srin...@wso2.com wrote: +1 On Wed, Nov 19, 2014 at 11:27 AM, Kasun Indrasiri ka...@wso2.com wrote: Hi, At the moment 'Call' mediator offers a blocking messaging behavior on top of non-blocking architecture (i.e. - Request and responses are handled in different threads). However, there are requirements where we need to support pure blocking messaging such as JMS transaction scenarios (which we use Callout mediator at the moment). However, having 'Call' and 'Callout' mediators is very confusing for the users and we need to have a single mediator with both capabilities. Hence we can add the blocking support as part of the Call mediator and deprecate Callout mediator. Thanks, -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Kathees Software Engineer, email: kath...@wso2.com mobile: +94772596173 -- Kathees Software Engineer, email: kath...@wso2.com mobile: +94772596173 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Server - Authenticating with Identity Server from API Store
On Mon, Feb 23, 2015 at 5:43 PM, Ranga Siriwardena ra...@wso2.com wrote: Hi All, During the API Manager Key Manager separation, we identified that we will need to authenticate to identity components as signed in user instead of admin user which is pre-configured in api-manager configuration. For example, Lets say we have two users called subscriber1 and subscriber2. When creating OAuth Applications we have to call Oauth Admin Service as particular user so that, this user can retrieve his/her applications only. For this purpose we are facing two issues. 1) User has to sign in to Identity side admin services with basic authentication (using username and password). But password is not available in API store for this requirement. 2) User has to have permissions defined for particular admin service. In this case user need to have /permission/admin/manage permission to access OAuth Admin Service. As a solution for the first issue we can use mutual-auth, so that identity server(Key Manager) can trust API store when accessing admin services. For the second problem, one option we identified is changing permission required for OAuth Admin Service. So from API Manager side we can give that required permission to API store users (users who has subscriber role). For this we will need to patch IS component to achieve this requirement. I think mutual SSL will resolve 1st issue as ranga mentioned. For second issue we may create new service with only operations required to non admin users and associate loose set of permissions to it (i didnt looked at operations in service but assume there are some admin operations and non admin operations) Thanks, sanjeewa. Please let us know if you have any concerns/thoughts about this. Thank You. Ranga. -- Ranga Siriwardena Software Engineer WSO2 Inc. -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 http://sanjeewamalalgoda.blogspot.com/blog :http://sanjeewamalalgoda.blogspot.com/ http://sanjeewamalalgoda.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
