Re: [Architecture] API Manager URI Templating broken use cases

[Colin Roy-Ehri]

Hi all,
I think it is important to deviate from the swagger specification only in
respects to making the URI verification more like what our customers
expect. More natural, more intuitive.  Intuitively, the URI mapping should
cover the URI, but query parameters are IMO, separate from the URI.  I am
+1 for allowing query parameters as optional, and not needing to define
resources with *.  There are many valid cases where adding the * for query
parameters can mess up an otherwise good URI scheme.  For example, one
customer wanted to have use the following URIs:

1. GET http://domain:port/context/1.0.0/orders?region="US";
2. GET http://domain:port/context/1.0.0/orders/orderid/123456

IMO, this seems like a valid, well ordered scheme, but we can't support it.
 the option 1 requires a resource with /orders* and the option 2 requires a
resource with /orders/orderid/{orderNumber}.  If we removed the necessity
for the * in a resource, it woudl allow optional query parameters.  We
would need to change our validation code to ignore query parameters during
URI template validation.  Besides, having * for URI validation is messy,
and should be avoided in general.  It does not adequately describe a
resource, so it makes the swagger documentation less useful.  We should
specify each query parmaeter individually anyway, and validate against the
query parameters we define.

So, in general, I'm for going with teh swagger definitions, but we should
not be constrained by them.  In particular, we should not force the * to be
used in a resource template when there are query parameters.

Cheers,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Fri, Oct 23, 2015 at 2:27 AM, Sanjeewa Malalgoda 
wrote:

>
>
> On Fri, Oct 23, 2015 at 11:03 AM, Joseph Fonseka  wrote:
>
>> Hi Sanjeewa
>>
>> On Thu, Oct 22, 2015 at 1:47 PM, Sanjeewa Malalgoda 
>> wrote:
>>>
>>>
>>> Other important thing we should focus is define resources which do not
>>> accept query parameters.
>>>
>>
>> What would be a use case for this ? Usually in APIs we simply ignore the
>> additional query parameters.
>>
> Some scenarios we don't want to have query parameters.
> Some of users use this pattern to avoid lengthy urls and malformed urls.
> They basically want to get only matching requests in.
> As per spec those are optional and client can decide sending them or not.
>
>>
>>
>>
>>> And other important usage of * is create APIs for services which does
>>> not implemented completely.
>>> As example we can have this kind of resource
>>>
>>> /bookStore/{bookID}*
>>>
>>> In future backend service implementation may have
>>> /bookStore/{bookID}/move
>>> /bookStore/{bookID}/transfer
>>> etc.
>>>
>>> So its not necessary query parameters but those are control verbs in
>>> resource path(no query parameters).
>>> So we may need to focus on that aspect as well.
>>>
>>
>> Above use case can be handled by using  "/bookStore/{bookID}{/paths*}"
>> which will qualify above paths see [1].
>>
> if it supports both having control verbs and not having them its good i
> think. So we may go for that.
> i think following will support with that
> /bookStore/123   GET
> /bookStore/123/move  POST
>
>
>
> Thanks,
> sanjeewa.
>
>
>>
>> Thanks
>> Jo
>>
>>
>> [1] https://tools.ietf.org/html/rfc6570#section-3.2.6
>>
>>
>>
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Thu, Oct 22, 2015 at 12:00 PM, Joseph Fonseka 
>>> wrote:
>>>
>>>>
>>>>
>>>>> Do you think we can migrate Resources of APIs which have been defined
>>>>> with * without breaking existing clients?
>>>>>
>>>>
>>>>  For API manager it is possible but this affects the existing ESB users
>>>> as well for them it would be a manual migration.
>>>>
>>>> 4. Support full URI Templates in ESB and only support what is supported
>>>>>> in swagger in API Manager.
>>>>>>
>>>>>
>>>>> I don't think it's a good idea to limit ourselves to what swagger
>>>>> supports.
>>>>>
>>>>
>>>> Yes that make sense going forward swagger might adopt the URI
>>>> Templating. If so we have following two options.
>>>> 1. Do nothing and clearly inform users if unsupported URITemplate is
>>>> used it wi

Re: [Architecture] ITERATE MEDIATOR

[Colin Roy-Ehri]

Hi John,
Inside the Iterate mediator, use a  mediator, then use the
 mediator in the OutSequence.  For reference, please see this
iterate/aggregate sample (1) or the EIP guide here (2).  In the EIP
example, a clone mediator is used instead of iterate, but the aggregate
functions in the same way.

(1)
http://susinda.blogspot.com/2015/02/wso2-esb-iterateaggregate-sample.html
(2) https://docs.wso2.com/display/IntegrationPatterns/Aggregator

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Wed, Sep 16, 2015 at 1:15 PM, John Q  wrote:

> Colin, thanks for your answer, actually I am using the iterate mediator,
> the problem is that I want to receive the original message, iterate over
> all the items calling the service for each one and finally call another
> service onlye once, but the service is invoked many times.
>
> this is what I have now:
>
> 
>  
>here I call the service for the item...
> 
> 
> here I call the service to notify
>
> the notify service is been invoked per each item...
>
> On Wed, Sep 16, 2015 at 1:11 PM, Colin Roy-Ehri  wrote:
>
>> Hi John Q,
>>
>> The aggregate mediator is used for exactly this purpose (1).
>>
>> (1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator
>>
>> Thanks,
>> Colin Roy-Ehri
>> Software Engineer
>> *WSO2, Inc. : wso2.com <http://wso2.com/>*
>> *Mobile*  : 812-219-6517
>>
>> On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:
>>
>>> Hello, I´m beginner and I need some help with the ESB.
>>>
>>> This is my situation:
>>>
>>> I will receive a message with many items, I need to iterate the items
>>> list and call a service for creating each item. At the end of all of the
>>> calls, I need to call another service to notify the end of items creation.
>>>
>>> how can I do it? I have used the iterate mediator and I have iterated
>>> the items well, but I don´t know how to wait until the last item is created
>>> and call the notify service only once. I have called the notify service
>>> outside the iterator mediator, but it is invoked once per each item
>>> iterated.
>>>
>>> can any body give me a clue?
>>>
>>> best regards...
>>>
>>> ___
>>> 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] ITERATE MEDIATOR

[Colin Roy-Ehri]

Hi John Q,

The aggregate mediator is used for exactly this purpose (1).

(1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:

> Hello, I´m beginner and I need some help with the ESB.
>
> This is my situation:
>
> I will receive a message with many items, I need to iterate the items list
> and call a service for creating each item. At the end of all of the calls,
> I need to call another service to notify the end of items creation.
>
> how can I do it? I have used the iterate mediator and I have iterated the
> items well, but I don´t know how to wait until the last item is created and
> call the notify service only once. I have called the notify service outside
> the iterator mediator, but it is invoked once per each item iterated.
>
> can any body give me a clue?
>
> best regards...
>
> ___
> 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] Digest authentication for secured endpoints in API Manager

[Colin Roy-Ehri]

+1 to the Oauth MAC Token profile soon.  Having the Digest auth would also
be good - More options for the customer. :)

I found an article Prabath wrote about the benefits of the Oauth MAC
profile a few years ago [1].  It's lightweight, more secure than the Oauth
2 bearer token request, and it doesn't need TLS to be secure.

[1] https://dzone.com/articles/oauth-20-bearer-token-profile

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Wed, Sep 2, 2015 at 1:05 PM, Prabath Siriwardena 
wrote:

> In my view - supporting OAuth MAC Token Profile [1] is high priority than
> this...
>
> [1]: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05
>
> Thanks & regards,
> -Prabath
>
> On Wed, Sep 2, 2015 at 1:02 PM, Prabath Siriwardena 
> wrote:
>
>> I guess you are talking about the HTTP Digest Authentication as in  RFC
>> 2617.
>>
>> The challenge in digest auth is the user store should store passwords in
>> cleartext (or encrypted - but not hashed) or should store the hash value of
>> username:password:realm.
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Wed, Sep 2, 2015 at 12:27 AM, Tharika Madurapperuma 
>> wrote:
>>
>>> Hi All,
>>>
>>> We currently have Basic auth to support secure endpoints in API
>>> Manager. We hope to provide a "Digest auth facility" as well, in our next
>>> release 1.10, in order to ensure better security.
>>>
>>> In this feature, the client(The API Developer) will have the
>>> ability to select the authentication type he or she requires as either
>>> Basic auth or Digest auth.
>>>
>>> If the client selects Digest auth as the preferred
>>> authentication type, the password is never sent over the network in plain
>>> text whenever the client requests access to a resource. What we send is
>>> only a hash.
>>>
>>> The following diagram explains the digest authentication process in
>>> a nut shell.
>>>
>>>
>>>
>>> ​
>>> I will further explain it here.
>>>
>>> 1. The client sends a request to the backend for accessing the resource.
>>>
>>> 2. The backend receives the request and sends back a 401 Authentication
>>> required message indicating that the client’s request has generated an
>>> unauthorized  access error.
>>>
>>> 3. Then the client extracts the required information from the message
>>> sent by the backend and generates hashes as shown by the source code below.
>>>
>>> HA1 = md5(username:realm:password)
>>> HA2 = md5(requestMethod:uri)
>>> Hash = md5(HA1:serverNonce:nc:cnonce:qop:HA2)
>>>
>>> The * realm* is a string which is used as part of the hash. It is the
>>> name of the domain that contains the account indicated by the user name.
>>>
>>> The *qop*(Quality Of Protection) can be one of auth, auth-int etc. and
>>> has influence on how the hash is created. We use auth here.
>>>
>>> The *serverNonce* is a unique code, which is used within the hash and
>>> needs to be sent back by the client to the backend.
>>>
>>> The above are the essential information gathered from the 401 response
>>> sent by the backend.
>>>
>>> Then the *username* and the *password* supplied by the client, the
>>> realm, the serverNonce and the qop sent by the backend are used for the
>>> creation of the hash along with the following as well.
>>>
>>> The *nc* is the Nounce count which is a hexadecimal serial number for
>>> the request. The client should increase this number by one for every
>>> request. It is the number of times the client has sent a challenge response
>>> by using the nonce. The nonce must be specified if a "qop" directive is
>>> sent.
>>>
>>> The * cnonce* is a unique id generated by the client. This nonce
>>> represents a challenge issued by the client to the server when immediate
>>> authentication of the server is desired. It can also be used to chosen
>>> plain text attacks.
>>>
>>> The *uri* is the authentication uri of the requested resource and the 
>>> *request
>>> method* can be one of GET, POST, etc.
>>>
>>> 4. The final Hash generated here is then sent to the backend for
>>> authentication, incorporated in an authentication header along with the
>>> following content.
>>>
>>> The us

Re: [Architecture] Cannot switch out certificates easily - we need a better solution across the platform

[Colin Roy-Ehri]

Hi Maninda,

When dynamically setting the keystore and truststore as you specify, does
this allow easy decryption and re-encryption of the passwords encrypted
with securevault?

Thanks,
Colin

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Fri, Jul 10, 2015 at 3:38 PM, Maninda Edirisooriya 
wrote:

> Hi Colin,
>
> In [1] we can dynamically set the key stores and trust stores at runtime
> without restarting the servers. It is available from ESB 4.9.0. But
> unfortunately as you say there seems no way to add/remove certificates from
> the key stores / trust stores at the run time. It is better to implement
> that capability as an API/admin service to the Carbon servers.
>
> [1] https://docs.wso2.com/display/ESB490/Multi-HTTPS+Transport
>
> Thanks.
>
>
> *Maninda Edirisooriya*
> Senior Software Engineer
>
> *WSO2, Inc.*lean.enterprise.middleware.
>
> *Blog* : http://maninda.blogspot.com/
> *E-mail* : mani...@wso2.com
> *Skype* : @manindae
> *Twitter* : @maninda
>
> On Fri, Jul 10, 2015 at 10:27 AM, Colin Roy-Ehri  wrote:
>
>> Hi all,
>>
>> I noticed that we don't have a good solution for users to switch out
>> primary certificates for all our products.  In a recent support case (1), a
>> customer simply wants to update their CA-issued certificate, and it's a
>> headache!  This is not tenable.  For high security scenarios, such as those
>> involving federal agencies, it is sometimes a requirement to have a
>> certificate that has only a 12, 18 or 24 month expiration time.  With
>> multiple environments, that means certificates need to be changed with
>> regularity.  This should be very easy with our products.  Why is it a
>> struggle to change the registry and primary certificate?  I would have
>> thought we had resolved this with a simple solution before now.
>>
>> Please let me know if there is an easy solution that I don't know about!
>>
>> (1) see the email subject:  Can not start dss server after installing a
>> new ssl certificate
>>
>> Thanks,
>> Colin Roy-Ehri
>> Software Engineer
>> *WSO2, Inc. : wso2.com <http://wso2.com/>*
>> *Mobile*  : 812-219-6517
>>
>> ___
>> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Cannot switch out certificates easily - we need a better solution across the platform

[Colin Roy-Ehri]

Hi all,

I noticed that we don't have a good solution for users to switch out
primary certificates for all our products.  In a recent support case (1), a
customer simply wants to update their CA-issued certificate, and it's a
headache!  This is not tenable.  For high security scenarios, such as those
involving federal agencies, it is sometimes a requirement to have a
certificate that has only a 12, 18 or 24 month expiration time.  With
multiple environments, that means certificates need to be changed with
regularity.  This should be very easy with our products.  Why is it a
struggle to change the registry and primary certificate?  I would have
thought we had resolved this with a simple solution before now.

Please let me know if there is an easy solution that I don't know about!

(1) see the email subject:  Can not start dss server after installing a new
ssl certificate

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Enrich Mediator should check for xsi:nil

[Colin Roy-Ehri]

Hi,

I came across an potential enhancement for the enrich mediator.  Currently,
the enrich mediator does not check if an element has an xsi:nil attribute.
I think enrich should check for xsi:nil and remove it.

Currently, if an xml or soap message has an element with xsi:nil, you can
use enrich mediator to add content:

Mediator config:

> 
> 
> 
> 


Before Enrich:

> http://www.w3.org/2001/XMLSchema-instance";
> xsi:nil="true"/>


After Enrich:

> http://www.w3.org/2001/XMLSchema-instance";
> xsi:nil="true">enrichedValue



Unfortunately, the second message violates the XML spec for xsi:nil (1),
because any element with xsi:nil must be empty.  I think we should change
the enrich mediator to check for xsi:nil attributes.  This is only
necessary if the enrich source is NOT inline, because inline source
enrichment overwrites attributes already.

WDYT?

(1) from http://www.w3.org/TR/xmlschema-1/ :

> 2.6.2 xsi:nil
> XML Schema: Structures introduces a mechanism for signaling that an
> element should be accepted as ·valid· when it has no content despite a
> content type which does not require or even necessarily allow empty
> content. An element may be ·valid· without content if it has the attribute
> xsi:nil with the value true. An element so labeled *must be empty*, but
> can carry attributes if permitted by the corresponding complex type.


Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB] Can we get rid of the usage of get-property function?

[Colin Roy-Ehri]

+1
It would be great to simplify the options available for property lookup.  I
think this would increase the usability of our product.  I am also
concerned about customers migrating their existing xml code.

In order to gain performance by moving away from get-property, would
customers need to revise all their use of these mediators?  I support
deprecating the get-property from the UI wizard and Dev Studio, but it
would also be great to revise the get-property implementation for future
versions.  In other words, would it be possible to change the get-property
implementation so that proxies, APIs and sequences could be migrated
forward without change, and still use the more efficient scoped-style
efficient implementation?  This would prevent the registry performance hit,
and prevent the necessity for customers to modify all their xml code.



Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Wed, Jun 17, 2015 at 2:41 AM, Kasun Indrasiri  wrote:

> Hi,
>
> It seems we can get rid of the usage of get-property and stick to the
> usage of scope variable declarations only (the current impl of get-property
> function always triggers a call to ESB registry interface, which can be a
> performance hit).
>
> For example we can use:
>
> $ctx, $trp etc to get required property values from the context.
> @Nadeeshan : we need to include $registry: as well.
>
> Any other use cases that we need to cover?
>
> --
> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Deprecate support for WSDL endpoint in API Manager.

[Colin Roy-Ehri]

+1
I've seen some recent support cases with the WSDL endpoint, due to exactly
the issues you mention.  It would be nice to deprecate it.

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Thu, May 7, 2015 at 2:06 AM, Sanjeewa Malalgoda 
wrote:

> +1. I don't see issue with remove that.
>
> Thanks,
> sanjeewa.
>
> On Thu, May 7, 2015 at 11:26 AM, Vijayaratha Vijayasingam  > wrote:
>
>> Hi Joe;
>>
>> ESB uses wsdl endpoints so we also added that support in APIM. But ,
>> AFAIK, there is no any advantage having wsdl endpoint support at
>> APIManager.WSDL endpoints are used to point a code generate tool to
>> generate stubs out of that WSDL.
>>
>> From APIManager we have option to provide wsdl. So users can generate
>>  client code out of that from store.
>> So, having a separate wsdl endpoint support is actually not required.
>>
>> Thanks.
>>
>> On 7 May 2015 at 11:14, Joseph Fonseka  wrote:
>>
>>> Hi All
>>>
>>> In offline discussions it was propose to drop support for WSDL endpoint
>>> in API manager. Following are some of the points made in the discussions.
>>>
>>> 1. Same functionality can be achieved using other endpoints.
>>> 2. There can be production level issues due to non availability of WSDL.
>>>
>>> If we are deprecating we need to provide a proper migration process for
>>> users that might be using WSDL endpoint.
>>>
>>> Please share your thoughts.
>>>
>>> Thanks
>>> Jo
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --
>>> *Joseph Fonseka*
>>>  WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>
>>>
>>
>>
>> --
>> -Ratha
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Export and Import APIs

[Colin Roy-Ehri]

Hi Sanjeewa,

I know there are some changes in swagger import and edit management coming
in the new APIM version.  Will we be able to guarantee that the swagger
definition will be totally reproducible from the exported API definition?
If so, then we should not include swagger in the API export.  If the
customer has some comments or details in the swagger YAML or JSON, which
are not reflected in the API definition, then we may need to export and
import the swagger along with the API definition, even if they will only be
used for reference by the customer.

+1 for using a C-App.

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Wed, May 6, 2015 at 2:39 PM, Isabelle Mauny  wrote:

> I am sorry, I don't understand your logic and I am +1 with Harshana (HI
> there !)
>
> This is not about importing and exporting APIs, it's about enabling the
> automated deployment of API artifacts across multiple environments. That's
> the target goal- Import and export is a side-effect of that-Let's focus on
> that first - How the file will be generated underneath is an implementation
> detail.-
>
> We need to create a packaged delivery application, which contains the API
> defintion, it's meta-data, attached description (WADL, WSDl, etc.) ,
> attached docs (files, URLs.) - If we don't do that, we don't fulfill the
> requirement of passing a FULL API definition across environments.
>
> The CApp *is* the archive- And we need to desing the structure of that
> CApp. If we do something else, people will have to repackage their APIs
> when we move to a CApp. I think the priority is to design the
> contents/structure of that archive.
>
> Thanks,
> Isabelle.
>
> -
> *Isabelle Mauny*
> VP, Product Management - WSO2, Inc. - http://wso2.com/
>
>
>
> On Wed, May 6, 2015 at 10:58 AM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Wed, May 6, 2015 at 11:30 AM, Harshana Eranga Martin <
>> harshan...@gmail.com> wrote:
>>
>>> Hi Thilini,
>>>
>>> I think this is a very useful feature for the platform. API Management
>>> users are going to benefit from this a lot as we have been facing the issue
>>> for long time with multiple environments.
>>>
>>> I have few concerns about the implementation though. Please see the
>>> comments inline.
>>>
>>> Thanks and Regards,
>>> Harshana
>>> --
>>> Harshana Eranga Martin
>>> Senior Software Engineer
>>> Asian Mobile Banking
>>> Web: https://www.commbank.com.au/ <http://wso2.com>
>>>
>>> ECF Committer: http://www.eclipse.org/ecf/
>>> Blog: http://harshana05.blogspot.com
>>> Profile: https://www.google.com/profiles/harshana05
>>>
>>> On 6 May 2015 at 11:43, Thilini Cooray  wrote:
>>>
>>>> Hi,
>>>>
>>>> *Regarding Isabelle's concerns,*
>>>>
>>>> a) This feature will be available as a custom application. Therefore we
>>>> decided to package this as a WAR.
>>>>
>>>
>>> I think it is not right to export APIs as a WAR file. WAR is already a
>>> well known file extension allocated for Web-Apps. It is going to complicate
>>> the life of users of both Web-Apps and API Management feature.
>>>
>>
>> Actually its not the archive format for APIs.
>> What they meant was they develop this rest API (for archive APIs) as
>> jax-rs application and bundled it as WAR file in away that we can deploy in
>>  API Manager server.
>> Then you will call to that JAX-RS service and request archived APIs and
>> it will return as .zip file.
>> You will get that data as multipart form data or any other format.
>>
>>
>>> I also believe as Isabelle suggested exporting the API as an artifact in
>>> the C-App would be the best mechanism. This will allow you to implement a
>>> new C-App artifact deployer for API manager and introduction of new
>>> Artifact type with an artifact structure. This Artifact deployer will
>>> understand the artifact metadata structure and knows how to interpret the
>>> metadata as well as generation of the metadata and the artifact when
>>> someone requests to export from the Publisher App. This would be a clean
>>> way to implement the export and import feature.
>>>
>> Yes C-App would be good approach. But adding API is bit complicate
>> process that and adding sequence, proxy service etc. So i think we can
&

Re: [Architecture] Generic workflow executor across the platform

[Colin Roy-Ehri]

I agree, +1 for a form-based approach.  Being able to make changes there
and observe the output BPEL would help users learn the format and structure.


Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Sat, Apr 25, 2015 at 6:07 AM, Frank Leymann  wrote:

> Dear Pulasthi,
>
> having a way to define simple BPEL processes in a form-based manner would
> be great!  Do you have some details on this?
>
>
> Best regards,
> Frank
>
> 2015-04-20 8:42 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Frank,
>>
>> We thought of having a simple form based approach at user end. We will
>> use some BPELs as templates and get the inputs from a form to customize it.
>>
>> On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann  wrote:
>>
>>> Hi Pulasthi,
>>>
>>> when you have "users without BPEL knowledge" in mind, you assume that
>>> these users have programming skills, correct?  I.e. that they provide the
>>> "workflow process" in JavaScript, for example, correct?
>>>
>>> Or do you work on a new very easy-to-use workflow language?
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>>>
>>>> Hi Frank,
>>>>
>>>> I sent a separate mail[1] with the architecture. Our main objective was
>>>> to provide the workflow support for the events in IS and [1] was designed
>>>> to address that. Furthermore we plan to provide a way to easily configure a
>>>> workflow process and deploy it at BPS (for the users without BPEL
>>>> knowlege). The work for that is in progress and we will update with the
>>>> details soon.
>>>>
>>>> [1] [Architecture] Generic workflow support
>>>>
>>>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>>>>
>>>>> Hi Pulasthi, hi Tanja,
>>>>>
>>>>> can you provide a consolidated architecture figure, please?  Can you
>>>>> also position in your architecture BPS?  I assume the requirements you
>>>>> address by your architecture is the ability to create an "on-ramp 
>>>>> workflow"
>>>>> for ES, AM,... in a "fast" way, correct?
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Frank
>>>>>
>>>>> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>>>>>
>>>>>> Hi Tanya,
>>>>>>
>>>>>> The actual architecture is bit different from the one you mentioned
>>>>>> here (I'll send a separate mail with details). The executors are
>>>>>> responsible only for executing workflow in some manner (can be BPEL, Web
>>>>>> Service or even some java code), and they can be registered as OSGI
>>>>>> services. The persisting is done by the WorkflowManager before calling 
>>>>>> the
>>>>>> executor.
>>>>>>
>>>>>> The WorkflowRequestHandler is the one responsible for creating
>>>>>> workflow requests for an event, and handling the callback for the same
>>>>>> event. So, what you said can be achieved at this point by customizing the
>>>>>> workflow request creation (persist somewhere and provide link in workflow
>>>>>> request). Since you create asset disabled and enable it after workflow
>>>>>> completion it will work. However there are some events where we have to
>>>>>> wait till the workflow completion to perform the actual action. That was
>>>>>> the reason to persist the request. Also note that all workflow parameters
>>>>>> are not set to the workflow executor. We can filter out parameters that
>>>>>> won't be needed at workflow (I will send those details in a separate 
>>>>>> mail).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Johann and all,
>>>>>>>
>>>>>>> As per the offline chat with Pulasthi, the executor serialize the
>>>>>>> workflow info and save in the database before calling the bpel service.
>>>>>>> (see th

Re: [Architecture] [APIM] Export and Import APIs

[Colin Roy-Ehri]

Hi!

I'm really excited about this feature - it will be of great benefit to our
customers.

I have no improvements to suggest on your implementation plan.

One point you might want to work into your tests is to ensure the swagger
definitions remain consistent after an import/export.  Of particular
concern is the swagger YAML definitions available through the publisher.
It shouldn't be too hard to code into a test. :)

Thanks,
Colin

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Wed, Apr 22, 2015 at 7:15 AM, Thilini Cooray  wrote:

> Hi all,
>
> We are in the process of introducing API Export and Import feature for
> WSO2 API Manager.
>
> This feature can be used in scenarios such as moving APIs from staging to
> production environment.
>
> *API Export*
>
>- This operation mainly sends an archive which consists of all the
>required resources for a API to be recreated in another API Manager
>instance.
>- We have identified following folder structure to be included in the
>archive
>
> ​
>
> ​
> *API Import*
>
>- Import feature accepts an API archive with the above mentioned
>structure and create a new API under current provider.
>
> *Feature Implementation*
>
>- Generating archive (in API export) and extracting archive (in API
>import) can either be done in server or client side
>- Currently we are planning to develop a RESTful API for export and
>import functionality where archive generation for requested APIs and all
>the related functionality are taken place in the server side.
>- Decision for server side implementation was mainly made due to high
>number of network calls and high possibility of network failures that can
>happen in client side.
>- The RESTful service is halfway done. currently it can export and
>import meta information only.
>   - *Export API* method calls  
> org.wso2.carbon.apimgt.api.APIProvider.getAPI(APIIdentifier)
>   and transforms received API object to a json file.
>   - *Import API* method receives json file via RESTful call and
>   converts the json to an API object. This object is then sent to
>   org.wso2.carbon.apimgt.api.APIProvider.addAPI(api) method and a new
>   API will get created.
>- Several concerns can arise with this implementation approach
>   1. API object can have environment specific details which are not
>   compatible with the  importing environment
>   2. There are some customisable attributes such as tiers (Ex : tiers
>   in exporting environment may not be available in importing side) which 
> may
>   not be available on the importing environment
>- Therefore we would like to know whether there is a better approach
>for implementing this.
>
> Suggestions and ideas for implementing this export import API feature is
> highly welcome.
>
> Thank you.
>
>
> --
> Best Regards,
>
> *Thilini Cooray*
> Software Engineer
> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
> E-mail : thili...@wso2.com
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> ___
> 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] Authorization server decoupling - Changes in configurations and in Server Profiles

[Colin Roy-Ehri]

Hi,

Adding an additional server profile adds additional complexity, and
separating the config files may help clarify this.  I highly recommend
extensive comments describing the different configurations within the new
xml file.  Also, adding comments to the renamed api-validator section of
the api-manager file would also be helpful.

In this new model, where would the authorize, revoke, and token gateway
APIs point?


Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Mon, Apr 6, 2015 at 5:14 AM, Amila De Silva  wrote:

> Hi All,
>
> Objective of this mail is to highlight the changes that needs to be done
> in server profiles and in configuration files while implementing this
> feature.
>
> As of now when Gateway receives a request, it talks to a server which
> performs the following operations;
>
> 1. Get details of the access token by querying the Database.
> 2. Check the validity of the token.
> 3. Check if the user is subscribed to the API.
> 4. Check if the token has necessary scopes to access the resource.
> 5. Generate JWT using details derived from the token.
>
> In this design, the server to which GW calls is the same entity which
> manages tokens. So calling this entity as Key Manager suits in this
> scenario.
>
> After decoupling the Authorization server, the server to which GW calls,
> will not be the same entity that manages tokens. To make this distinction
> clear, a new profile will be introduced (which we'll refer to as Key
> Validator for now). Basically GW calls to Key Validator which performs all
> the above operations except 1st and 2nd. To complete its validation, Key
> Validator obtains token details by calling to a Key Manager (Authorization
> Server) - which can either be the one shipped with APIM or else a third
> party one.
>
>
> 1st Diagram illustrates the interaction between server profiles we
> currently have and the second diagram shows the interactions after adding
> the new profile.
>
>
>
> ​
> Boxes in the diagram represent the profiles, not the server instances in a
> deployment. When using the inbuilt KM, a typical deployment will have
> KeyValidator and KeyManager profiles in the same JVM. All the server roles
> except Gateway, will have to know about Key Manager.
>
> These are the changes happening in configuration files;
>
> 1. Key-Manager section in api-manager.xml will be changed as Key-Validator
> a. TokenEndPointName and RevokeAPIURL elements will be removed from
> Key-Validator section.
> b. Two new elements ApplicationTokenScope &
> KeyValidationHandlerClassName will be introduced.
>
> 2. A new config named key-manager.xml will be introduced.
> Purpose of having this file is to provide a single location to keep all
> the settings, configs used by a KeyManager implementation.
>
> This is the structure of the key-manager.xml to be shipped with APIM by
> default.
>
>  xmlns="http://wso2.org/projects/apimgt/key-manager.xml";>
> 
>   https://localhost:9443/services/
> 
>   https://localhost:8243/token
>   https://localhost:8243/revoke
> 
> 
>
> Since generating/revoking tokens are done by the class implementing
> KeyManager interface, those urls have been moved in to this config.
>
> Contents inside the  block can change based on the
> implementing class. For example, when plugging in an third party Key
> Manager (Authorization Server), introspect endpoint might have to be
> provided.
>
> Please share your thoughts.
>
> --
> *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] ESB Mediator for WSO2 Machine Learner

[Colin Roy-Ehri]

+1 This configuration looks very neat and concise.

If the ML mediator will be primary used on a single domain, would it make
sense to include an optional domain attribute to the ML node?  I could see
two uses for an optional domain attribute:

1. It could be useful for logging, annotation and troubleshooting.
2. Perhaps it could be used as a default filter?



+



Perhaps 'target-domain' or 'domain-name' would be better than simply
'domain'.  Perhaps this is just duplicating functionality of the 'name'
attribute and filter mediator.  WDYT?

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Tue, Mar 24, 2015 at 12:00 PM, Manorama Perera  wrote:

> Hi,
>
> ESB mediator for WSO2 ML enables making use of the models generated by
> WSO2 Machine Leaner, to predict values in message mediation in ESB.
>
>- Machine Learner feature needs to be installed in ESB prior to
>configure the ML mediator.
>- Mediator will extract the data from the incoming messages and send
>to the ML model as features.
>- The mediator use the Machine Learner features to predict the output
>value for every message passing through the mediator.
>
> *Proposed Mediator Configuration*
>
> 
> 
> +
> 
> 
>
> *model*
> storage-location : Storage location of the generated model.
>
> *feature*
> name : Feature name according to the generated model.
> expression : XPath expression used to determine the feature value.
>
> *prediction*
> expression : XPath expression to determine the location to insert the
> predicted value.
>
> The generated models can be applied to predict only the data coming from
> the same domain, as the data used to train the model. So the mediator
> should be configured only to mediate messages which carry data coming from
> the same domain, as the data used to train the model.
>
> Any suggestion are appreciated.
>
> Thanks.
>
> --
> Manorama Perera
> Software Engineer
> WSO2, Inc.;  http://wso2.com/
> Mobile : +94716436216
>
> ___
> 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] [APIM] Swagger validation

[Colin Roy-Ehri]

+1 to validating it at the backend.
Also, there will be a challenge to inform the publisher with the validation
results, both success and detailed errors.   Also closing the import window
popup after a successful import would be nice.

Thanks!

Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Sat, Mar 21, 2015 at 8:40 AM, Madawa Soysa  wrote:

> Hi,
>
> Check the project[1] <https://github.com/swagger-api/swagger-parser> as
> well. This is not a json-schema validator but swagger specific parser which
> creates a Java POJO from a swagger definition. Includes a Swagger migration
> tool from Swagger 1.0, 1.1 and 1.2 to Swagger 2.0.
>
> [1] - https://github.com/swagger-api/swagger-parser
> <https://github.com/swagger-api/swagger-parser>
>
> On 20 March 2015 at 16:28, Madusanka Premaratne 
> wrote:
>
>> Hi Vishanth,
>> Thanks for the response. I did a research on fge/json-schema-validator
>> and seems like it is not maintaining.
>> Anyhow I will apply it and check whether it is functioning as expected.
>> Thanks,
>>
>> On Fri, Mar 20, 2015 at 2:46 PM, Vishanth Balasubramaniam <
>> vishan...@wso2.com> wrote:
>>
>>> Hi Madusanka,
>>>
>>> I too think the right approach is to validate at the backend.
>>>
>>> I came across this json schema validator project [1] sometime back,
>>> check if this is useful for you in some way.
>>>
>>> [1] - https://github.com/fge/json-schema-validator
>>>
>>> Regards,
>>> Vishanth
>>>
>>> On Fri, Mar 20, 2015 at 12:36 PM, Madusanka Premaratne <
>>> madusan...@wso2.com> wrote:
>>>
>>>> Hi all,
>>>> As you all know APIM uses YAML and Swagger. We have already done YAML
>>>> validation part and will be there as real time yaml syntax validator in the
>>>> upcoming release.
>>>>
>>>> ​In the validation of swagger we can either validate swagger at the
>>>> front-end using javascript or validate at the backend using json schema
>>>> validator.
>>>> According to the offline discussions I had with Colin and Jo, it is
>>>> more suitable to validate it at the backend, because there are two
>>>> ways(write/import) to feed a swagger doc.
>>>>
>>>> Does anyone worked with a json schema validator which can be used to
>>>> fulfil our need?
>>>>
>>>> Feedbacks and suggestions for this improvement would be appreciated.
>>>>
>>>> ​Thanks,​
>>>>
>>>> --
>>>> *Madusanka Premaratne* | Associate Software Engineer
>>>> WSO2, Inc | lean. enterprise. middleware.
>>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>>> Mobile: +94 71 835 70 73| Work: +94 112 145 345
>>>> Email: madusan...@wso2.com | Web: www.wso2.com
>>>>
>>>> [image: Facebook] <https://www.facebook.com/maduzanka> [image: Twitter]
>>>> <https://twitter.com/rmmpremaratne> [image: Google Plus]
>>>> <https://plus.google.com/u/0/+MadusankaPremaratnemaduz/about/p/pub> [image:
>>>> Linkedin] <http://lk.linkedin.com/in/madusanka/> [image: Instagram]
>>>> <http://instagram.com/madusankapremaratne> [image: Skype]
>>>> <http://@rmmpremaratne>
>>>>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> *Vishanth Balasubramaniam*
>>> Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94771737718*
>>> about me: *http://about.me/vishanth <http://about.me/vishanth>*
>>>
>>>
>>
>>
>> --
>> *Madusanka Premaratne* | Associate Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 835 70 73| Work: +94 112 145 345
>> Email: madusan...@wso2.com | Web: www.wso2.com
>>
>> [image: Facebook] <https://www.facebook.com/maduzanka> [image: Twitter]
>> <https://twitter.com/rmmpremaratne> [image: Google Plus]
>> <https://plus.google.com/u/0/+MadusankaPremaratnemaduz/about/p/pub> [image:
>> Linkedin] <http://lk.linkedin.com/in/madusanka/> [image: Instagram]
>> <http://instagram.com/madusankapremaratne> [image: Skype]
>> <http://@rmmpremaratne>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Madawa Soysa
> Software Engineering Intern | WS*O₂* Inc. <http://wso2.com>
>
> Mobile: +94 75 812 0726 | Email: mada...@wso2.com
> LinkedIn <http://lk.linkedin.com/in/madawasoysa> | Twitter
> <https://twitter.com/madawa_rc> | Tumblr <http://madawas.tumblr.com>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Issue: A publisher in APIPublisher can see only limited details about a particular API.

[Colin Roy-Ehri]

+1 For a publisher to be able to view all the configurations made by the
creator. Including custom mediation sequences, if any.
On Mar 11, 2015 7:10 AM, "Isabelle Mauny"  wrote:

> It used to be that the rest of the information on an API was read-only.
> The Manage tab MUST be editable by publisher.
>
> Isabelle.
>
>
> -
> *Isabelle Mauny*
> VP, Product Management - WSO2, Inc. - http://wso2.com/
>
> On Wed, Mar 11, 2015 at 10:56 AM, Supun Wijerathne 
> wrote:
>
>>
>> In APIPublisher in WSO2 API Manager, a publisher can only see the details
>> provided by the "overview" tab of info page of an API.
>>
>> Is it better to let a publisher see the information of an API which can
>> be seen with "Edit" link of info page. ( The same information a
>> creator/admin see, as uneditable) ?
>>
>> And, is it better to let a publisher to edit the details in Manage page
>> of an API ?
>>
>> Thanks.!!
>> --
>>
>> *Supun Wijerathne*
>> Software Engineering Intern.
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile: +94778591187
>> sup...@wso2.com
>> LinkedIn 
>>
>
>
> ___
> 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 Server - Mapping existing oAuth applications with API manager.

[Colin Roy-Ehri]

Hi Roshan,

I think this is an awesome new feature. +1

I see a small security concern with associating an OAuth client only with
the consumer key.  If they use the consumer key, they will then be able to
view the consumer secret.  This could be abused as a way to fetch the
secret key.  Perhaps both consumer key and secret should be necessary when
tying a new app to existing OAuth client.  Alternately, you could obscure
the secret for apps created like this (but that would require deeper
modification).

Cheers,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Tue, Mar 10, 2015 at 12:59 AM, Roshan Wijesena  wrote:

> Hi Isabelle,
>
> We could see possible two use cases as below,
>
> First, let say, a person uses an external  authorization server  and it
> contains already  created  oauth clients. Assume that user might want to
> use wso2 API manager with that  particular  authorization server, as a key
> manager. In that case If he/she wants to associate  already existing  oauth
> clients with API manager applications, there should be a  way to do it.
>
> Second, there might be a situation where a user  wants to create Oauth
> clients in their authorization server manually, (for example by using an
> API, Dynamic client registration API in OpenID connect). Then later user
> logging  in to APIM and create an APIM application and instead of creating
> a new oAuth client he/she should  be able to associate that manually
> created Oauth client with the API manager application.
>
> Both of the above use cases are more or less the same. The basic idea of
> this feature is, the store user will be given an opportunity to associate
> their manually created oAuth clients with API manager.
>
> Hi NuwanD,
>
> Yes,If they disable this feature from the config file it will only show
> the 'Generate' button. And these options are available for both production
> and sandbox environments.
>
> Regards
> Roshan.
>
>
> On Mon, Mar 9, 2015 at 7:39 PM, Nuwan Dias  wrote:
>
>>
>>
>> On Mon, Mar 9, 2015 at 6:21 PM, Isabelle Mauny  wrote:
>>
>>> I am not clear who the target user is or what the use case is. Can you
>>> share that please ?
>>>
>>> Isabelle.
>>>
>>>
>>> -
>>> *Isabelle Mauny*
>>> VP, Product Management - WSO2, Inc. - http://wso2.com/
>>>
>>>
>>> On Fri, Mar 6, 2015 at 5:08 PM, Roshan Wijesena  wrote:
>>>
>>>> Hi,
>>>>
>>>> When providing the capability to plug in an External Authorization
>>>> Server for managing tokens and clients, a need may also arise to associate
>>>> already existing Oauth clients with Applications created in API Manager.
>>>>
>>>> We are working on a solution to cater the above requirement. When users
>>>> log in to the store and navigate to the subscription page, they can decide
>>>> whether they want to an entirely new OAuth client or associate an existing
>>>> OAuth client with the Application in APIM side. Users can associate an
>>>> existing Oauth App by enabling a check box. If they check the option, they
>>>> will be given a text box to enter the consumer key of the oAuth client.
>>>> Once users click on generate button we will create a new mapping for that
>>>> consumer key with the API Manager application.
>>>>
>>>> If someone wants to disable this feature completely  they can turn it
>>>> off by changing  a config setting  from api-manger.xml config file.
>>>>
>>>
>> So if they disable it we will only show the 'Generate' button? Also,
>> these options are enabled for both 'Production' and 'Sandbox' as well
>> right?
>>
>>>
>>>> Regards
>>>> Roshan.
>>>>
>>>> --
>>>> Roshan Wijesena.
>>>> Senior Software Engineer-WSO2 Inc.
>>>> Mobile: *+94719154640 <%2B94719154640>*
>>>> Email: ros...@wso2.com
>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>> lean.enterprise.middleware.
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>> ___
>>> Architecture mailing li

Re: [Architecture] Fwd: [APIM] Decoupling Authorization Server - Additional features needed from IS to completely decouple Authorization Server from APIManager.

[Colin Roy-Ehri]

+1 for option 1.a. Because this admin feature should be accessible by the
Subscriber role.  Preventing that role from accessing the admin services
would complicate the use of the service.

Also, for point 3. "Exposing a service to register scopes & resources", the
new admin service access should be accessible by the Creator and/or
Publisher roles.

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Tue, Mar 10, 2015 at 1:39 PM, Amila De Silva  wrote:

> Hi All,
>
> While carrying out development, we came through several gaps that prevents
> IS to be seamlessly used as an Authorization Server.
> 1. Ability for subscribers to invoke OAuthAdminService.
> Subscribers log into the store create Applications , Subscribe to API and
> then Register the applications with Authorization Server (at this point an
> OAuth app is created in IS) to get Consumer Key/Secret pair. Until now API
> Manager has been registering Apps by directly writing to DB
> (IDN_OAUTH_CONSUMER_APPS , a table that should be written only through IS).
> But in future we’ll be creating the OAuthApp by calling OAuthAdminService.
> The problem  is, this being an admin service, only the users with admin
> privileges can invoke this. But subscribers log into the store are only
> required to have subscribe permission. Two options are available to solve
> this ;
>
> a. Reducing permission of the Admin Service.
>
> b. Changing the Service in such a way that an authenticated admin user
> can create an OAuth App behalf of another user.
>
> This issue is discussed in the thread "[APIM] Decoupling Authorization
> Server - Authenticating with Identity Server from API Store"
>
> 2. Need an additional grant handler for creating Application Access Tokens.
> Plans is to create Application Access Token using an extended grant type.
> For API Manager to work seamlessly with IS (without any feature
> installation), this new grant type needs to be shipped with IS.
>
> 3. Exposing a service to register scopes & resources
> At the time of creating an API, creators have the ability to indicate
> which scopes are needed for accessing a given resource. These scopes are
> referred when issuing an access token. Currently we are saving the scopes
> in IDN_OAUTH2_SCOPE table and resource-scope mapping in
> IDN_OAUTH2_RESOURCE_SCOPE table through a direct DB write. Since writing to
> these tables is the responsibility of the Authorization Server, a service
> should be provided for creating scopes & resources.
>
>
> 4. Checking whether the user is allowed to have a requested scope when
> issuing tokens
> API Manager has extended the default behaviour of issuing tokens. When a
> token is requested for a scope, IS issues the token without performing
> additional checks. In API Manager, a scope can be associated with a role,
> so that only the users having the particular role will be given access
> tokens generated for that scope. This implementation should also be shipped
> with IS.
>
> --
> *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] Deployable persistency while being deployed using cApps is problematic

[Colin Roy-Ehri]

>
>
> This is something the user is responsible that we don't have a control :(
> . StreamDefinition is something that can be generated even automatically,
> according to a message delivered to the server. Control is only on the user
> side. IMO, there is no specific reason for having two stream defs with the
> same name and the version. That is why I said if the same stream def is
> going to be saved, even if there is no conflicts, we have to fail that. if
> it is a car file deployment, entire carfile deployment gets failed and kept
> that as a faulty cApp.
>
>
Could it be feasible to add a UUID to the stream definition name or version
when checked in to the registry?  That would ensure uniqueness, but would
cause a deviation of the registry name/version from the capp name/version.
Perhaps we could work around user laziness (not renaming or versioning) by
adding a UUID only if a duplicate name/version is present in the registry.

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517
___
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

[Colin Roy-Ehri]

+1 for these enhancements.

I wonder if #1 the Extended Grant Type could cause unnecessary complexity
for the External Authorization server?  I think #1 is a necessary feature,
but we could make simple grant types an option.  For initial configuration
of an External Authorization server, it may be easier to work with the
default Oauth2 Grant Types.  Perhaps we could have a configuration point
for the External Authorization server, i.e.  .  Just
an idea.

-Colin

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com <http://wso2.com/>*
*Mobile*  : 812-219-6517

On Mon, Feb 16, 2015 at 5:53 AM, Amila De Silva  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] Should the OPTIONS call be terminated at the API gateway.

[Colin Roy-Ehri]

I agree that an OPTIONS request should not expose backend service methods,
and should in most cases not be sent to the backend.  In some customer
cases, such as I saw in New Zealand,  customers require the OPTIONS call to
be passes through to the backend for a response.

One elegant solution would be to have the default /* resources not include
the OPTIONS method.  In the absence of an explicitly defined api OPTIONS
resource, of course an app calling OPTIONS should return the methods
defined in the API.

I look forward to having CORS work better with this kind of enhancement.  :)

-Colin
On Jan 24, 2015 3:20 AM, "Isuru Udana"  wrote:

> Hi All,
>
> Following statement is extracted from the spec[1]
>
> "If no Max-Forwards field is present in the request, then the forwarded
> request MUST NOT include a Max-Forwards field."
>
> So according to this, if the header is not present, request can be forward
> to the backend. But it doesn't clearly say whether we must forward the
> request or not. But it is more natural to forward the request rather
> blocking it as this is an optional header.
>
> I'm not sure how good it is to have a global property to control this as
> it will affect all the APIs in the server (For most of the APIs, request
> might need to be forwarded to backend in absence of this header)
> Can we do this at the synapse configuration level without altering the
> synapse code ?
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>
> Thanks.
>
> On Tue, Jan 13, 2015 at 3:25 PM, Amila De Silva  wrote:
>
>> Doing this as a mediation extension would make it more re-usable IMO.
>>
>> On Tue, Jan 13, 2015 at 3:10 PM, Ruwan Yatawara  wrote:
>>
>>> On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias  wrote:
>>>
 Ok, so I think we need to have a property which can be
 enabled/disabled. This property decides whether the OPTIONS request should
 be forwarded to the back-end or not. Whenever the Max-Forwards header is
 not present in the request, this property gets prominence. When present,
 Max-Forwards get prominence.

 And I think this needs to be done at the Synapse level rather than
 handling at an API Manager handler level.

>>>
>>> +1 including this in the Synapse level makes good sense.
>>>

 Thanks,
 NuwanD.

 On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka 
 wrote:

> Hi
>
> @Amila
> For options call we can respond per API basis, based on the HTTP
> methods defined in the API. And those methods can be sent via "Allow"
> header. Also the same methods can be sent in CORS headers too.
>
> @Nuwan
> Yes the Max-Forwards is the problem and according to the spec it is to
> be honored by proxy servers. But API Gateway is more of an API facade 
> which
> does masking so shouldn't it be hiding internal implementation details 
> from
> outside ? (Ex the implemented methods in the back-end server). If so then
> we should not send the OPTIONS call to the back-end.
>
> @Ruwan
> IMO we should return the OPTIONS call from Gateway also in ESB if the
> Max-Forwards is set to 0 it will return before hitting the in sequence.
>
> Thanks
> Jo
>
>
>
>
>
> On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara 
> wrote:
>
>> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
>>> wrote:
>>>

 Hi

 Currently in API Manager we send the OPTIONS call to the back-end
 server to respond. But if the API does not expose all the HTTP methods 
 in
 back-end, OPTIONS call response will be invalid.

 1. Should we respond to the OPTIONS call from the gateway with the
 Allow header including only the HTTP methods exposed by the API.

 2. If we are doing above should we give an option to the user to
 override in case if he want to send it to back-end.

>>>
>>> Whether the OPTIONS call goes to the back-end or not is dominated by
>>> the Max-Forwards header. According to the spec [1], it seems like the
>>> request should be forwarded when the Max-Forwards header is not present.
>>>
>>
>> First of all +1, but since we are implicitly enabling OPTIONS for the
>> API, and we are including a property that can be configured by the users 
>> if
>> they to enable sending options call to the back end (Which by the way 
>> needs
>> to be a configuration that can be done on a per API basis, i believe),
>> should we not introduce the Max-Forward : 0 header when intercepting the
>> options call at the gateway? and sending it back. Or should just the drop
>> the message and respond back, with the allow origin headers and what not?
>>
>>>
 3. Is there a valid requirement to show the OPTIONS method in AP