On Mon, Aug 15, 2016 at 12:12 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> > > On Mon, Aug 15, 2016 at 11:54 AM, Dinusha Senanayaka <[email protected]> > wrote: > >> 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. >> > Let say some non admin user logged into system and try to do certain > operations(create application do not require admin right but admin service > calls need to have it). In that case how normal users cookie can be use to > admin service call. I have came a across this issue multiple times and i > don't see cleaner solution as users always do not have admin permissions to > call services. > @Sanjiwa, We could achieve this by assigning the required permission to relevant user role . For an example, when adding a XACML policy assign '../entitlement/policy/manage/add', '../entitlement/policy/manage/view' , etc to creator role. Like wise there is a narrowed down permission list for each service where we could restrict the accessibility. > As you said having separate service and use server to server communication > is a good solution as i understood. This service should be called from > another service and service should be able to do certain validation and > handle tenant flow within it. Then after that it should call PEP service > locally using java APIs(this should be possible). For that we dont need to > have any modifications from IS side as they already have APIs for those > services. Then you need to install features into identity server and it > will be headache at some point. Still it would be a good solution than > letting any user to call tenant admin services. > > Thanks, > sanjeewa. > >> >> >> 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 >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
