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. > Yes i'm thinking about this scenario. Ideally when we create publisher role we should identify all underlying permissions they require(create update application, create update service provider etc) and create role. Then that validation can be done using existing services(if we have proper permissions in existing service) or by adding new service layer. Other alternative is underlying process by wrapped service. As example in API Manager you have subscribe role. Then API Key Management subscriber service will take care of creating SP on behalf of logged in user(using server to server communication as privileged user) and other required stuff. Then the service need to be super tenant deployed tenant aware admin service. This pattern is also used in many places in our code based and i don't see major issue with this approach as well(person who design service should take care of it). Thanks, sanjeewa. > > 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 > > -- *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
