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
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to