Hi all, We agreed upon to proceed with 'domain' parameter to filter Application and Internal roles as well. This will be applicable to *role* filtering. In case of filtering *Users* using roles, domain parameter for that case should only take user store domain roles.
Thanks, On Fri, Jul 26, 2019 at 10:50 AM Isura Karunaratne <is...@wso2.com> wrote: > Hi Sarubi, > > AFAIK, all the endpoints in the Identity Server behave Internal / > Application roles same as secondary user stores. In fact, we can treat it > is a separate user store. > > What are the disadvantages of implementing the domain parameter support > for Internal/Applications roles? > > I am +1 the fix for the consistency. > > On the other hand, how can we search for all the Application roles which > are ending with some characters? > > Ex. > > *https://localhost:9443/scim2/Groups?filter=displayName+ew+ > <https://localhost:9443/scim2/Groups?filter=displayName+sw+>**cation* > > In such cases, If we don't have the domain parameter, there is no way to > filter Application roles only. > > Cheers, > Isura. > > > > > > > > On Fri, Jul 26, 2019 at 10:36 AM Sarubi Thillainathan <sar...@wso2.com> > wrote: > >> Hi Denuanthi/All, >> >> The purpose of introducing the domain parameter is to specify the >> specific domain (that is user store) which the user wants to query out >> regardless of roles (/Groups endpoint) or users (/Users endpoints). Hence >> it is not suitable to mix up with the WSO2 roles type in it because users >> don't contain any internal or application types. Because the requirement >> which you specified only applicable for the /Groups endpoint not for /User >> endpoints. So I'm -1 to mix up. >> >> If the user wants to query out the internal/hybrid roles they can use, >> *curl -v -k --user admin:admin >> 'https://localhost:9443/scim2/Groups?filter=displayName+sw+ >> <https://localhost:9443/scim2/Groups?filter=displayName+sw+>* >> *Application/**app'* >> instead of as you specified, >> >>> *curl -v -k --user admin:admin >>> 'https://localhost:9443/scim2/Groups?filter=displayName+sw+app&; >>> <https://localhost:9443/scim2/Groups?filter=displayName+sw+app&;>domain=Application'* >> >> >> So far I don't see any blocker for the users to query the internal/hybrid >> roles. If we really want to have a query parameter for it, it's better to >> introduce a new parameter to specify the roles types only for the /Groups >> endpoint. According to the SCIM specification, we can support an >> additional parameter if we want, since the internal/hybrid roles are only >> specific for our Identity Server. >> >> Thanks, >> Sarubi. >> >> On Thu, Jul 25, 2019 at 1:16 PM gayan gunawardana < >> gmgunaward...@gmail.com> wrote: >> >>> >>> >>> On Thu, Jul 25, 2019 at 12:39 PM Denuwanthi De Silva < >>> denuwan...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> 1. In WSO2 Identity Server, when filtering roles/groups through SCIM >>>> API, internal roles are not filtered. >>>> Ex: internal roles >>>> -*Internal*/system >>>> -*Application*/myapp >>>> >>>> Sample filter request: >>>> *curl -v -k --user admin:admin >>>> 'https://localhost:9443/scim2/Groups?filter=displayName+sw+Application >>>> <https://localhost:9443/scim2/Groups?filter=displayName+sw+Application>'* >>>> >>>> We need to support for above type of filtering. >>>> >>> I suppose for SCIM specification there is no speciality with Internal >>> roles. Hence +1 to support above feature. >>> >>>> >>>> 2. >>>> When considering role types in WSO2 Identity Server. There are mainly 2 >>>> types. >>>> 1.userstore domain based roles ex: PRIMARY/myrole >>>> 2. internal/hybrid roles ex:Application/myapp >>>> >>>> We have introduced a new parameter to filter users and roles using a >>>> 'domain' parameter recently. >>>> >>>> *Ex: curl -v -k --user admin:admin >>>> 'https://localhost:9443/scim2/Groups?filter=displayName+sw+myrole&; >>>> <https://localhost:9443/scim2/Groups?filter=displayName+sw+myrole&;>domain=Primary'* >>>> >>> >>>> Here users and roles can be filtered according to the userstore domain. >>>> >>>> *So, my question is do we have to support this new domain based filter >>>> for internal roles as well?* >>>> *ex: curl -v -k --user admin:admin >>>> 'https://localhost:9443/scim2/Groups?filter=displayName+sw+app&; >>>> <https://localhost:9443/scim2/Groups?filter=displayName+sw+app&;>domain=Application'* >>>> >>>> one concern I have is, >>>> 1.Application domain is not necessarily a userstore domain. Therefore >>>> whether it is correct to mix those domains. >>>> >>> I think better approach is having two type of parameters for user store >>> domains (domain) and for internal roles (say type). But type parameter >>> should be able to support multiple values such as Internal, Application. >>> >>>> >>>> >>>> Please provide your thoughts on this. >>>> >>>> Thanks, >>>> -- >>>> Denuwanthi De Silva >>>> Associate Technical Lead; >>>> WSO2 Inc.; http://wso2.com, >>>> Email: denuwan...@wso2.com >>>> Blog: https://denuwanthi.wordpress.com/ >>>> https://medium.com/@denuwanthi.hasanthika >>>> Contact No: 0771391097 >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>> >>> >>> -- >>> Gayan >>> _______________________________________________ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >> >> >> -- >> *Sarubi Thillainathan* | Software Engineer | WSO2 Inc. >> (m) +94 (0) 76 684 9101 | (e) sar...@wso2.com,stsa...@gmail.com >> >> *[image: https://wso2.com/signature] <https://wso2.com/signature>* >> > > > -- > > *Isura Dilhara Karunaratne* > Technical Lead | WSO2 <http://wso2.com/> > *lean.enterprise.middleware* > Email: is...@wso2.com > Mob : +94 772 254 810 > Blog : https://medium.com/@isurakarunaratne > > > > -- Denuwanthi De Silva Associate Technical Lead; WSO2 Inc.; http://wso2.com, Email: denuwan...@wso2.com Blog: https://denuwanthi.wordpress.com/ https://medium.com/@denuwanthi.hasanthika Contact No: 0771391097
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
