Hi All, 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. > I think there are two scenarios here. 1. Non admin user (i I'll say less privileged ) login to the system and trying to do a high privileged action. Eg : User login the publisher (need admin/manage/Web-App/publisher ) and trying to create SP on behalf of this user with which needs *admin/manage * 2. Less privileged user login to the system or no user at all but need to do a privileged action. Eg. To validate the access token gateway talk to Keymanager token validation service. In the fist case the issues is privileged levels are not matched, this is the case in App manager use case as well. To over come this issue I think we need to review the permission in each services define the permissions accordingly. In the 2nd case we may use server to server authentication mechanism to over come this issues. And I don't believe that providing a separate service will solve the initial issue but may introduce new dependency issues between products. So my suggestion it. Change the permission level for SP creation services. Introduce cookie base authentication for PEP service. Thanks, Ishara > 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 > > -- Ishara Karunarathna Associate Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
