Hi Frank, Yes we have tested and it is working fine.
In addition to the four use cases mentioned above, a user is also allowed to download documents as well as seeing their meta-data from a different tenant domain. As a summary, all the use cases for Store that currently support cross-tenant invocations are as follows: 1. Get all APIs from a different tenant domain. 2. Get a specific API from a different tenant domain. 3. Get documents (meta-data) of an API which is in a different tenant domain. 4. Get an specific document (meta-data) of an API which is in a different tenant domain. 5. Get the content of a specific document of an API which is in a different tenant domain. Thanks, Malintha. On Sat, Nov 28, 2015 at 7:11 PM, Frank Leymann <[email protected]> wrote: > Thanks, Malintha! > > I assume we verify that a user is allowed to access resources from a > different tenant domain? > > > Best regards, > Frank > > 2015-11-22 18:48 GMT+01:00 Malintha Amarasinghe <[email protected]>: > >> Hi, >> >> Yes we have implemented it in the way Sanjeewa mentioned in the previous >> mail. Due to the complexity and inconsistency (with the requests which does >> not require tenant domain) of having the tenant domain as the part of the >> context, we decided to send it as a query/header parameter. According to >> the current implementation, we have used a header parameter. >> >> A sample request would be as follow: >> >> >> - User "[email protected]" wants to see what are the APIs that are >> available in the tenant cloud.com >> >> *GET* http://127.0.0.1:9764/api/am/store/v1/apis HTTP/1.1 >> *X-WSO2-Tenant*: cloud.com >> *Authorization*: *Basic* *Or Bearer token* >> >> >> >> We identify the user's tenant domain from the authorization header. If he >> need to lookup resources of a different tenant domain, he can send it from >> the *X-WSO2-Tenant *header. This is only supported in Store for >> following use cases. >> >> 1. User wants to get all APIs from a different tenant domain. >> 2. User wants to get a specific API from a different tenant domain. >> 3. User wants to see documents of an API which is in a different tenant >> domain. >> 4, User wants to see a specific document of an API which is in a >> different tenant domain. >> >> Thank you. >> Malintha. >> >> >> >> On Sun, Nov 22, 2015 at 9:49 PM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> Hi frank, >>> As we discussed during last meeting tenant domain will not be a part of >>> context. So application url remain as it is and current logged tenant will >>> identified using authentication details client send(we start tenant flow >>> based on logged in user). >>> If need we can make tenant name query parameter in url. >>> Requested tenant can be transport header and part of API. >>> >>> I think malintha already implemented this for some resources which >>> requires requested tenant. He may provide more information. >>> >>> Thanks >>> sanjeewa. >>> >>> sent from my phone >>> On Nov 22, 2015 7:14 PM, "Frank Leymann" <[email protected]> wrote: >>> >>>> Dear all, >>>> >>>> let me try to understand: >>>> >>>> A user ([email protected]) wants to access a resource created by a >>>> certain tenant (cloud.com) - correct? The tenant created the resource >>>> and we decided to make the tenant-id part of the context of the resource's >>>> URL. >>>> >>>> Thus, the user who wants to access the tenant's resource is a parameter >>>> of some sort of (new?) API that requests access to the tenant's resource. >>>> >>>> This (new?) API would look something like this: >>>> >>>> <host>/<context>/{tenant}/<API-name>/<parameters>&[email protected] >>>> >>>> Does it make sense or did I miss the discussion? >>>> >>>> >>>> >>>> Best regards, >>>> Frank >>>> >>>> 2015-11-17 16:16 GMT+01:00 Sanjeewa Malalgoda <[email protected]>: >>>> >>>>> If we think this very carefully requested tenant domain should be part >>>>> of the API. >>>>> Let me explain it, >>>>> We have API and that behave in some manner according to provided >>>>> parameters and inputs. >>>>> In this particular scenario, we are passing completely different data >>>>> set and get different results. >>>>> So cant we take this as user input for API? If we added that as >>>>> parameter then it will be part of API(non mandatory parameter). >>>>> >>>>> Or else we may need to have ability of setting custom fields in carbon >>>>> context as that can be accessible across all places of started flow. >>>>> But according to current implementation we cannot place anything in >>>>> carbon context. >>>>> With tenant app sharing concept we need to have logged in tenant and >>>>> requested tenant both in message context to give proper results. >>>>> Shouldn't we have that capability in carbon context? >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 2:20 PM, Malintha Amarasinghe < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> In API Manager REST API, we will be supporting cross tenant >>>>>> scenarios. Few examples would be like below. >>>>>> >>>>>> 1. [email protected] wants to see the APIs that are available in the >>>>>> tenant store; cloud.com >>>>>> 2. [email protected] wants to see the documents of an API weatherAPI >>>>>> that are available in the tenant store; cloud.com >>>>>> >>>>>> For this requirement we need to pass the "required tenant domain" >>>>>> parameter with the request as the logged in user belongs to is a >>>>>> different >>>>>> tenant. There are several possible ways to specify this. >>>>>> >>>>>> 1. Specify this as a query parameter for every resource this is >>>>>> required >>>>>> >>>>>> ex: GET >>>>>> http://127.0.0.1:9763/api/am/publisher/v1/apis?*tenantDomain=cloud.com >>>>>> <http://cloud.com>* >>>>>> >>>>>> >>>>>> 2. Specify this as a header parameter >>>>>> >>>>>> 3. Specify this within the URI. >>>>>> >>>>>> a. before the Jax-RS web app context >>>>>> >>>>>> ex: GET http://127.0.0.1:9763/*t/cloud.com <http://cloud.com>* >>>>>> /api/am/publisher/v1/apis >>>>>> >>>>>> b. after the Jax-RS web app context >>>>>> >>>>>> ex: GET http://127.0.0.1:9763/api/am/publisher/v1/*t/cloud.com >>>>>> <http://cloud.com>*/apis >>>>>> >>>>>> >>>>>> Regarding these three options, option (3.a) would require the web app >>>>>> to be deployed on each and every tenant. Or otherwise we should manually >>>>>> register contexts in tomcat run-time to match those contexts. Even if we >>>>>> register context manually, this would not be a good solution as the user >>>>>> might expect the web app to be in the tenant space (when he sees the >>>>>> /t/tenant part in the URI) but it is not there actually. Option (3.b) >>>>>> would >>>>>> require the web app to handle the tenant as a resource and every other >>>>>> resource would need to be a sub-resource. And we need to specifically >>>>>> handle for the super tenant which we don't specify the tenant in the URL. >>>>>> For options (1) and (2), we don't need to face such difficulties. >>>>>> >>>>>> Please share your thoughts. >>>>>> >>>>>> Thanks. >>>>>> Malintha >>>>>> >>>>>> -- >>>>>> Malintha Amarasinghe >>>>>> Software Engineer >>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>> http://wso2.com/ >>>>>> >>>>>> Mobile : +94 712383306 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>> >> >> >> -- >> Malintha Amarasinghe >> Software Engineer >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> > > -- Malintha Amarasinghe Software Engineer *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
