Hi Amalka, I had a offline chat with AmilaD and some discussed things were as follows. The idea of a user being in many groups is arose when we do a design review in the beginning and in the requirement also. But It was ignored and implemented this in a way in which user is in one group because if you want to consider a user should be in many groups, you can achieve it in following two ways
1. User will login on behalf of one group. In that case groupId will be extracted from login request and apps and subscriptions belongs to that group, will be shown to him. user will login on behalf of another group. then user will see the apps and subscriptions belongs to that group in the same as before. 2. You can create a sub theme in APIM store for this. In sub theme you have to implement the following logic. i. get the groupIds via login response. ii. retrieve apps and subscriptions for each groupId. iii. show them on store in relevant places. need to check on the feasibility on this option. Thanks On Thu, Jan 14, 2016 at 12:12 PM, Amila De Silva <ami...@wso2.com> wrote: > You have to set an empty value for the claim. > > On Thu, Jan 14, 2016 at 12:09 PM, Amalka Subasinghe <ama...@wso2.com> > wrote: > >> Hi Amila >> >> I don't understand how appowner sees all the Apps which belongs to >> different groups on same APIM screen. >> I tested this in APIM setup, but when a one user has 2 groupIds, he/she >> could see the Default application only. >> >> >> On Thu, Jan 14, 2016 at 10:28 AM, Amila De Silva <ami...@wso2.com> wrote: >> >>> Hi Amalka, >>> >>> Apparently when the AppOwner logs in without a groupId, he/she sees all >>> the Apps (even the one's created with different groupIds) in the same >>> screen. >>> So the problem would only be there for AppDevelopers. >>> >>> Answering to your query; it depends on how you get the group Id. If we >>> assume that SSO is enabled at Store, when trying to login directly to >>> Store, users (only talking about App Owners here) will be re-directed to an >>> IDP, and whatever the groupId set from IDP will be used for fetching Apps. >>> If the IDP doesn't set a groupId, all the apps will be shown. >>> >>> On Thu, Jan 14, 2016 at 8:35 AM, Amalka Subasinghe <ama...@wso2.com> >>> wrote: >>> >>>> >>>> With this Amila's explanation; when a appowner login to the APIM via >>>> two different apps of AF, will see two different views in APIM. >>>> If the same appowner login to the APIM directly, what will he see in >>>> APIM? >>>> >>>> I believe when a user login to the APIM; (either via AF or directly), >>>> he should see the same view every time. (if that user belongs to two >>>> different groups he should see all subscriptions belongs to all groups). >>>> >>>> >>>> On Wed, Jan 13, 2016 at 11:05 PM, Amila De Silva <ami...@wso2.com> >>>> wrote: >>>> >>>>> Hi Danushka/Amalka, >>>>> >>>>> It's not that the scenario of user belonging to two or more groups is >>>>> not supported in the current version. It's only that the way it currently >>>>> happens slightly differs from how you need it. >>>>> >>>>> What we are basically trying to achieve is, displaying Apps, >>>>> subscriptions when user belongs to two or more groups. A single user can >>>>> have many group Ids, but in a single session user can only have one group >>>>> Id. >>>>> AFAIU, with the existing implementation following can be achieved; >>>>> 1. AppOwner creates 2 Apps in AppF , App1 (with groupId as >>>>> appowner1_app1) and App2 (groupId being appowner1_app2). >>>>> 2. I assume Apps in APIM gets automatically created while doing 1. >>>>> 3. AppOwner selects App1 in AppF and tries to see the relevant App in >>>>> APIM. >>>>> 4. AppOwner is re-directed to API Store with groupId set as >>>>> appowner1_app1 (need to discuss how/where this is set) >>>>> 5. AppOwner is logged into the Store as a user with groupId >>>>> appowner1_app1, therefore only sees App1. >>>>> 6. AppOwner logs out from Store. >>>>> 7. AppOwner goes to AppF and selects App2, follows a link that >>>>> re-directs to APIMStore. >>>>> 8. AppOwner now goes to Store as a user in appowner1_app2 group, so >>>>> only sees App2. >>>>> >>>>> To view each App, user would need to make a trip back to the AppF. It >>>>> might be possible eliminate step 6, and if it's so, we might have to >>>>> change >>>>> subscription.jag (and several other jags) to clear out the groupId set in >>>>> the session, and set the one coming with the request. There are few points >>>>> that needs to be discussed more with the above steps, but this would be >>>>> the >>>>> way it would look like. >>>>> >>>>> It's true that the default group Id extractor gets the group Id from >>>>> http://wso2.org/claims/organization claim, but it doesn't have to be >>>>> like that in every case. In the very first time it was written thinking >>>>> that Group ID is coming with the SAML Response sent back from IDp. >>>>> >>>>> On Wed, Jan 13, 2016 at 6:37 PM, Danushka Fernando <danush...@wso2.com >>>>> > wrote: >>>>> >>>>>> Hi Nuwan >>>>>> The issue of adding extension to cloud is we have to add it to API >>>>>> cloud and it will affect all API cloud users who don't use APP cloud >>>>>> also. >>>>>> And since multiple groups per user seems to be a valid use case how >>>>>> complex will this be to implement? >>>>>> >>>>>> Thanks & Regards >>>>>> Danushka Fernando >>>>>> Senior Software Engineer >>>>>> WSO2 inc. http://wso2.com/ >>>>>> Mobile : +94716332729 >>>>>> >>>>>> >>>>>> On Jan 13, 2016 3:53 PM, "Lakshman Udayakantha" <lakshm...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Nuwan, >>>>>>> >>>>>>> Even though we have extracted multiple group ids using group id >>>>>>> extractor, DAO classes use one group id to extract the applications and >>>>>>> subscriptions. I think we have to implement to get all the applications >>>>>>> and >>>>>>> subscriptions if user are in several groups. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On Wed, Jan 13, 2016 at 2:18 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jan 13, 2016 at 12:32 PM, Amalka Subasinghe < >>>>>>>> ama...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi Nuwan, >>>>>>>>> >>>>>>>>> We need APIM support to show subscribed API, when there's 1 user >>>>>>>>> assigned to 2 user groups. >>>>>>>>> >>>>>>>>> *Our current AF APIM integration flow works as follows.* >>>>>>>>> >>>>>>>>> let's say we have a tenant foo.com and users - appowner1 and >>>>>>>>> developer1 >>>>>>>>> App owner1 creates an AF application 'AFapp1' and assign devloper1 >>>>>>>>> as a developer of that application. >>>>>>>>> according to the current implementation only the appowner1 can >>>>>>>>> subscribe to the APIM API. >>>>>>>>> [When appowner1 login to the APIM, we create an application >>>>>>>>> 'AFapp1' in APIM side and selecting that application appowner1 can >>>>>>>>> subscribe to an API] >>>>>>>>> Then appowner1 can see subscribed APIs in AF side, where >>>>>>>>> developers can't see that API. >>>>>>>>> >>>>>>>>> So we need to implement APIM group subscriptions in AF. >>>>>>>>> to implement it we have to set the organization claim (as eg: >>>>>>>>> 'foo.com_AFapp1') for appowner1 and developer1. >>>>>>>>> Then both users can see the subscribed API. >>>>>>>>> >>>>>>>>> *We have another use case;* >>>>>>>>> basically our user grouping happens per AF application and 1 user >>>>>>>>> can be in 2 groups >>>>>>>>> >>>>>>>>> Let's say appowner1 creates an another application AFapp2 >>>>>>>>> then appowner1 is belongs to 2 user groups. So we need to assign >>>>>>>>> two values for the organization claim. (foo.com_AFapp1, >>>>>>>>> foo.com_AFapp2) >>>>>>>>> appowner1 want to see subscribed API in APIM side based on that 2 >>>>>>>>> organizations. >>>>>>>>> >>>>>>>>> As I know, APIM does not support this when there's a more than 1 >>>>>>>>> group assigned for the organization claim. >>>>>>>>> But this is a required use case for the AF/cloud, and we can't >>>>>>>>> customize the GroupingExtractor due to maintainability issues in >>>>>>>>> cloud. >>>>>>>>> >>>>>>>>> Can this improvement provide by APIM? >>>>>>>>> >>>>>>>> >>>>>>>> It can be done. But we've already done product plans for releases >>>>>>>> covering the year. It might take time to get this into the product as >>>>>>>> a GA >>>>>>>> release. I guess the timely solution is to customize the >>>>>>>> GroupingExtractor. >>>>>>>> >>>>>>>> What maintainability concerns do you have? If a standard extension >>>>>>>> point in the product is a maintainability concern it makes no sense to >>>>>>>> have >>>>>>>> those extension points at all. So I would like to understand those >>>>>>>> concerns >>>>>>>> and improve if possible. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Amalka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 12, 2016 at 1:42 PM, Amalka Subasinghe < >>>>>>>>> ama...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Currently only the app owner allows to subscribed to an API, >>>>>>>>>> generate keys and see subscribed APIs, where other users are not >>>>>>>>>> allowed as >>>>>>>>>> showed in the below table. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Subscribe to API Generate Keys View subscribed APIs in AF side View >>>>>>>>>> Prod keys in AF side View Sandbox keys in AF side App owner Y Y Y >>>>>>>>>> Y Y Developer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Y QA >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Y DevOps >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Y Y >>>>>>>>>> We want to improve the AF - APIM integration as follows. So we >>>>>>>>>> need implement $subject. >>>>>>>>>> 1. making both app owner and developer can subscribe to an API >>>>>>>>>> and generate keys >>>>>>>>>> 2. making all users to see subscribed API per application >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Subscribe to API Generate Keys View subscribed APIs in AF side View >>>>>>>>>> Prod keys in AF side View Sandbox keys in AF side App owner Y Y Y >>>>>>>>>> Y Y Developer Y Y Y >>>>>>>>>> Y QA >>>>>>>>>> >>>>>>>>>> Y >>>>>>>>>> Y DevOps >>>>>>>>>> >>>>>>>>>> Y Y Y >>>>>>>>>> *Things to do:* >>>>>>>>>> >>>>>>>>>> 1. All the users of a particular app we need to maintain as a >>>>>>>>>> group. >>>>>>>>>> >>>>>>>>>> In APIM side they uses http://wso2.org/claims/organization claim >>>>>>>>>> to group the users. We have to set this claim (eg: app key as the >>>>>>>>>> value of >>>>>>>>>> the claim) when appowner or developer try to click on 'Go to API >>>>>>>>>> Manager' >>>>>>>>>> button. >>>>>>>>>> Currently we use a role app_appName to group the users of a >>>>>>>>>> particular application in AF. If we use this we have to implement a >>>>>>>>>> custom >>>>>>>>>> grouping extractor to get the users of a particular group. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Issues: *a. Since we don't set the claim for QA and DevOps >>>>>>>>>> users, they can't view subscribed APIs in AF side, and If we add the >>>>>>>>>> claim >>>>>>>>>> they also will be able to subscribe to APIs and generate keys. So we >>>>>>>>>> need >>>>>>>>>> to find a way to view subscribed api for a particular application by >>>>>>>>>> QA and >>>>>>>>>> Devops users. >>>>>>>>>> b. With this implementation Developer can see prod keys also. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. Make Go to API Manager and Sync Keys buttons enabled only to >>>>>>>>>> appowner and developer. >>>>>>>>>> For this we can use resource permissions we already have. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3. Need to improve/test all the rest calls we do with APIM to >>>>>>>>>> work with groups and fix if there's any issue. >>>>>>>>>> >>>>>>>>>> - Login - When user clicks on 'Go to API Manager' button of a >>>>>>>>>> particular app, it should login to APIM and show the subscribed >>>>>>>>>> APIs, >>>>>>>>>> listed under selected application. >>>>>>>>>> - Create application >>>>>>>>>> - Remove application >>>>>>>>>> - Get published APIs by application >>>>>>>>>> - List subscription >>>>>>>>>> - Get applications >>>>>>>>>> >>>>>>>>>> [1] https://wso2.org/jira/browse/APPFAC-3217 >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Amalka >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Amalka Subasinghe >>>>>>>>> Senior Software Engineer >>>>>>>>> WSO2 Inc. >>>>>>>>> Mobile: +94 77 9401267 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Technical Lead - WSO2, Inc. http://wso2.com >>>>>>>> email : nuw...@wso2.com >>>>>>>> Phone : +94 777 775 729 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lakshman Udayakantha >>>>>>> WSO2 Inc. www.wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> Mobile: *0714388124* >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> Dev@wso2.org >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Amila De Silva* >>>>> >>>>> WSO2 Inc. >>>>> mobile :(+94) 775119302 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Amalka Subasinghe >>>> Senior Software Engineer >>>> WSO2 Inc. >>>> Mobile: +94 77 9401267 >>>> >>> >>> >>> >>> -- >>> *Amila De Silva* >>> >>> WSO2 Inc. >>> mobile :(+94) 775119302 >>> >>> >> >> >> -- >> Amalka Subasinghe >> Senior Software Engineer >> WSO2 Inc. >> Mobile: +94 77 9401267 >> > > > > -- > *Amila De Silva* > > WSO2 Inc. > mobile :(+94) 775119302 > > -- Lakshman Udayakantha WSO2 Inc. www.wso2.com lean.enterprise.middleware Mobile: *0714388124*
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
