Also Jira[1] to track 'Cookie base authorization to PEP proxy' [1] https://wso2.org/jira/browse/IDENTITY-4987
On Mon, Aug 15, 2016 at 4:40 PM, Rushmin Fernando <[email protected]> wrote: > Created a Jira [1] to track SP creation permission improvement. > > [1] - https://wso2.org/jira/browse/IDENTITY-4988 > > On Mon, Aug 15, 2016 at 12:50 PM, Ishara Karunarathna <[email protected]> > wrote: > >> 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 >> >> > > > -- > *Best Regards* > > *Rushmin Fernando* > *Technical Lead* > > WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware > > mobile : +94772891266 > > > > _______________________________________________ > 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
