Hi All, We need to find a solution for this ASAP, as this blocking AppM Cloud integration.
Problem: Currently App Manager register a service provider per each app to support SSO. This SP is registered in super tenant space and marked as a SAAS app. But as a part of getting App Manager into cloud we need to register this SP in each tenant space. Same with XACML policy registration and evaluation too. Registered in super tenant space with tenant domain prefix added to name. Solution that we were trying is to get a cookie using *SAML2SSOAuthenticator * (This solves the need of keeping credentials per tenant to call admin services) and use it to call these admin services. We faced two issues on doing it. [1] PEP Service does not support cookie based authorization [2] SP registration related admin services do not have fine grained permission. It need admin/manage permission which breaks the publisher permission model if we assign it to publisher users. We need help from identity team to provide fix for [1] and [2]. May be Rushmin or Lahiru from AppM team can check it and send PR if you can provide some guidance. Other solution for initial issue is, AppM need to come with a feature like key-manager feature in APIM, which can install in Identity Server. I do not like to go for this solution because of the deployment complexities it introduce. Currently we do not need any modification from Identity Server side, we just configure AppM to call IS by addition IdP information in app-manager.xml. If we go with feature installation, then we have all the problems APIM is having now to align compatible dependency etc. Johann/IS-team: Appreciate your thoughts on this. Regards, Dinusha. On Mon, Aug 15, 2016 at 11:05 AM, Rushmin Fernando <[email protected]> wrote: > Hi Harsha, > > It is the 'publisher' app/API both roles are using. So I don't think that > we can use a mechanism which depends on contexts. Anyway could you please > share a documentation of the new API security model, if there is any ? > > Best Regards > Rushmin > > On Sun, Aug 14, 2016 at 8:14 PM, Harsha Thirimanna <[email protected]> > wrote: > >> If you have separate context for each, then you can have separate >> permission for each context using above new API security model using valve. >> Is that solved your problem ? >> >> *Harsha Thirimanna* >> Associate Tech Lead | WSO2 >> >> Email: [email protected] >> Mob: +94715186770 >> Blog: http://harshathirimanna.blogspot.com/ >> Twitter: http://twitter.com/harshathirimann >> Linked-In: linked-in: http://www.linkedin.com/pub/ha >> rsha-thirimanna/10/ab8/122 >> <http://wso2.com/signature> >> >> On Thu, Aug 11, 2016 at 12:21 PM, Rushmin Fernando <[email protected]> >> wrote: >> >>> Hi Ishara, >>> >>> We have a concern with giving admin/manager permission to the 'creator' >>> role. (to create service providers) >>> >>> As a business logic in App Manager, a 'creator' shouldn't be able to >>> publish an app. But the if we give admin/manage permission a creator will >>> get the 'publish' permission as well. >>> >>> Is there a possibility to have fine-grained permission for SP creation >>> in the next component release ? e.g. admin/manager/sp/create >>> >>> Best Regards >>> Rushmin >>> >>> On Tue, Aug 9, 2016 at 8:13 AM, Harsha Thirimanna <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> Yes, We were tying to solve this problem in generic manner that can be >>>> used across the platform. For that, we have written a component to register >>>> authentication handler and the interceptors to intercept rest call. For now >>>> we have written Basic and OAuth token base handlers. But anyone can write >>>> custom handlers and register as a OSGi to use by the interceptors. As >>>> Interceptors , we wrote common tomcat valve and hope to write servlet >>>> filter and cxf filter. >>>> >>>> You also can intercept the request in your own place and authenticate >>>> the request using our generic component. It has a manager class to do the >>>> authentication. Handler will pick based on can handle method by handler >>>> manager. >>>> >>>> In addition, we have develop another interceptor point to do the >>>> authorization and it is also like same authentication component. You can >>>> write your own handlers, and intercept by any place. We have written an >>>> another valve as interceptor and authorization handler check the permission >>>> as configure in identity.xml as follows. >>>> >>>> <ResourceAccessControl> >>>> <Resource context="/api/identity/*" secured="true" >>>> http-method="all"> >>>> <Permissions>/permission/admin/login</Permissions> >>>> </Resource> >>>> <Resource context="/api/test" secured="true" >>>> http-method="put,post"> >>>> <Permissions>/permission/admin/test</Permissions> >>>> </Resource> >>>> </ResourceAccessControl> >>>> >>>> We are going to release 1.0.0 M1 with next upcoming milestone in 5.3.0. >>>> Your ideas welcome to improve this component in more generic manner. >>>> Please let us know anything related to this. >>>> >>>> >>>> >>>> >>>> >>>> *Harsha Thirimanna* >>>> Associate Tech Lead | WSO2 >>>> >>>> Email: [email protected] >>>> Mob: +94715186770 >>>> Blog: http://harshathirimanna.blogspot.com/ >>>> Twitter: http://twitter.com/harshathirimann >>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>>> rsha-thirimanna/10/ab8/122 >>>> <http://wso2.com/signature> >>>> >>>> On Tue, Aug 9, 2016 at 4:00 AM, Farasath Ahamed <[email protected]> >>>> wrote: >>>> >>>>> Hi Rushmin, >>>>> >>>>> On Mon, Aug 8, 2016 at 4:14 PM, Rushmin Fernando <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks Ishara ! >>>>>> >>>>>> Since our products are adopting OAuth protected ReST APIs, is there >>>>>> an OAuth authencator being developed and planed to be developed ? >>>>>> >>>>> >>>>> Harsha has worked on developing a generic component that can be used >>>>> by OAuth protected REST APIs[1]. Adding Harsha as he can provide more >>>>> details on this. >>>>> >>>>> [1] https://github.com/wso2-extensions/identity-carbon-auth-rest >>>>> >>>>> >>>>> >>>>>> Regards, >>>>>> Rushmin >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 8, 2016 at 4:04 PM, Ishara Karunarathna <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hi Dinusha, >>>>>>> >>>>>>> In this case I think publisher user should be able to create those >>>>>>> SP, XACML policies etc. >>>>>>> Since publisher use is within the publisher role you can assign >>>>>>> necessary permission to that role. >>>>>>> Once user login (SSO) to publisher with his credential he can get a >>>>>>> cookie for that >>>>>>> and he can use that cookie to authenticate to the admin services. >>>>>>> >>>>>>> @Rushmin, >>>>>>> We don't have a authenticator for OAuth token. Better to get a ID >>>>>>> token using OIDC or after validating OAuth token >>>>>>> and create a carbon authenticator like saml carbon authenticator. >>>>>>> >>>>>>> Thanks, >>>>>>> Ishara >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 8, 2016 at 3:47 PM, Rushmin Fernando <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> In addition to creating these entries from the UI, we need to >>>>>>>> create the same using our ReST API as well. And the API is OAuth >>>>>>>> protected. >>>>>>>> >>>>>>>> Is there an authenticator which gives back a cookie for an OAuth >>>>>>>> token as well ? >>>>>>>> >>>>>>>> On Mon, Aug 8, 2016 at 3:29 PM, Ishara Karunarathna < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Lahiru. >>>>>>>>> >>>>>>>>> >>>>>>>>> Its not the admin user.User trying to do this operation should >>>>>>>>> have enough permission to do this. >>>>>>>>> >>>>>>>>> Use >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *entitlement/policy/view* >>>>>>>>> >>>>>>>>> Add this permission to the user who is trying to view those policies. >>>>>>>>> >>>>>>>>> >>>>>>>>> BR, >>>>>>>>> >>>>>>>>> Ishara >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 8, 2016 at 3:20 PM, Lahiru Cooray <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> + [DEV] >>>>>>>>>> >>>>>>>>>> On Mon, Aug 8, 2016 at 3:19 PM, Lahiru Cooray <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> *Current behaviour:* >>>>>>>>>>> Currently in AppM, when we are creating XACML policies/Service >>>>>>>>>>> Providers via IS admin services, we are providing the super tenant >>>>>>>>>>> admin >>>>>>>>>>> credentials (where the credentials are stored in a config) to get >>>>>>>>>>> authenticated. Further, XACML policies/Service providers are only >>>>>>>>>>> created >>>>>>>>>>> in super tenant and marked as a SAAS app to be used in tenants. >>>>>>>>>>> >>>>>>>>>>> *Problem:* >>>>>>>>>>> As we are moving for AppM - Cloud integration, we are trying to >>>>>>>>>>> deploy these in relevant tenant spaces. So as a solution we have >>>>>>>>>>> tried to >>>>>>>>>>> use *SAML2SSOAuthenticator*[1] (retrieving a cookie passing >>>>>>>>>>> the SAML response and use the same in subsequent service calls) but >>>>>>>>>>> figured >>>>>>>>>>> that this is not applicable for non admin users. >>>>>>>>>>> (*eg:* In AppM user story, non admin users should be allowed to >>>>>>>>>>> create apps with XAML policies) >>>>>>>>>>> >>>>>>>>>>> Any suggestions for this would be highly appreciated! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] https://github.com/wso2/carbon-identity/blob/8cd996c1dc6 >>>>>>>>>>> d9e7c0df491322af6e9ddf1cf3709/components/carbon-authenticato >>>>>>>>>>> rs/saml2-sso-authenticator/org.wso2.carbon.identity.authenti >>>>>>>>>>> cator.saml2.sso/src/main/java/org/wso2/carbon/identity/authe >>>>>>>>>>> nticator/saml2/sso/SAML2SSOAuthenticator.java >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Lahiru Cooray* >>>>>>>>>>> Software Engineer >>>>>>>>>>> WSO2, Inc.;http://wso2.com/ >>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>> >>>>>>>>>>> Mobile: +94 715 654154 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Lahiru Cooray* >>>>>>>>>> Software Engineer >>>>>>>>>> WSO2, Inc.;http://wso2.com/ >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> Mobile: +94 715 654154 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ishara Karunarathna >>>>>>>>> Associate Technical Lead >>>>>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>>>> >>>>>>>>> email: [email protected], blog: isharaaruna.blogspot.com, >>>>>>>>> mobile: +94717996791 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Best Regards* >>>>>>>> >>>>>>>> *Rushmin Fernando* >>>>>>>> *Technical Lead* >>>>>>>> >>>>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> mobile : +94772891266 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ishara Karunarathna >>>>>>> Associate Technical Lead >>>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>> >>>>>>> email: [email protected], blog: isharaaruna.blogspot.com, >>>>>>> mobile: +94717996791 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Best Regards* >>>>>> >>>>>> *Rushmin Fernando* >>>>>> *Technical Lead* >>>>>> >>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>> >>>>>> mobile : +94772891266 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> *Best Regards* >>> >>> *Rushmin Fernando* >>> *Technical Lead* >>> >>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>> >>> mobile : +94772891266 >>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> > > > -- > *Best Regards* > > *Rushmin Fernando* > *Technical Lead* > > WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware > > mobile : +94772891266 > > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Dinusha Dilrukshi Associate Technical Lead WSO2 Inc.: http://wso2.com/ Mobile: +94725255071 Blog: http://dinushasblog.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
