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 >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
