On Sat, May 31, 2014 at 1:00 AM, Dilshan Edirisuriya <[email protected]> wrote:
> I am also -1 to that but not sure whether there is a solution if the point > 1) is not fulfilling with the use of API manger APIs. Have to check this > with API manager team. I just have proposed a work around by looking at > AppFactory. > > > On Sat, May 31, 2014 at 12:52 AM, Chan <[email protected]> wrote: > >> -1 for keeping passwords in files. They are evil cause people will change >> them from UI and behavior is unpredictable. Best is to authenticate with >> the identity token we have to the APIM. I am not sure whether APIM supports >> authenticating with SAML token? >> >> >> On Fri, May 30, 2014 at 11:30 AM, Dilshan Edirisuriya <[email protected]> >> wrote: >> >>> Hi, >>> >>> This is related to the API manager integration with EMM. To describe >>> more on the usecase we are trying to protect some of the EMM APIs (for now >>> only Android) using API manager. For this we have included the API manager >>> features to EMM pack along with the publisher and API store Jaggery apps. >>> >>> We have discussed 2 approaches on this in Dev [1] other than the >>> approach discussed in [2]. After discussing with Shan we are going ahead >>> with the approach 1 which is discussed in thread [1]. Which is to have one >>> consumer key and consumer secret for super tenant space and make it >>> available for all other tenant. So at any time an EMM server instance will >>> only contain one consumer key and a consumer secret. >>> Yes This is convenient if we want use same android agent across multiple >>> tenants. >>> >> > >>> While progressing in the development I have faced some issues. Which >>> needs to be clearly defined and addressed. >>> >>> Since above APIs are Android related these should be published and >>> subscribed in advance. What I was asked to do is to automatically publish >>> and subscribe APIs into the API manager. After disusing with Sumedha we >>> thought of doing it using API manager REST api. >>> >> The same requirement in the G-reg also what they have done is use startup publisher rather using REST APIs. Currently this feature is available for super tenants only. By extending startup publisher we can make it available for all tenants. For automatically subscribe feature there is a decision to make either go with REST APIs or develop a component like start-up subscriber. In order to publish I went through the publisher APIs which appear in API >>> manager doc[3]. This requires login to the system in advance. I looked in >>> to the API manager code on this. As an example if you look at add publisher >>> API at location publisher/site/blocks/item-add/ajax/add.jag this has a >>> validation to check the current user (session.get("logged.user")). So it >>> fails from this point. I see following issues on this. >>> >>> 1) API manager does not accept a SAML token hence we need to call the >>> login url first to get a valid session in API publisher. Is there any way >>> we can achieve this? >>> >>> 2) If we are to call the login API of API manager we should keep the >>> username or password in some place like configuration file. I know >>> AppFactory do this where they keep admin credentials in appfactory.xml for >>> the purpose of WSRequests. Is it ok to follow something like this? >>> >> >>> 3) If we keep username and password in a configuration file it should be >>> super admin credentials since we need to publish/subscribe using that >>> account to be available for all other users. What if someone change the >>> credentials from carbon console before logging into EMM? >>> >> We can skip these issues if we don't select REST API way. > >>> 4) Not sure whether there is Jaggery listeners for context >>> initialization as in servlet spec (I know they have implemented listeners >>> for session though). Otherwise have to publish/subscribe these at first >>> time login which is bit non standard way of doing things. >>> >> Yeah this is non standard way of doing things. If we wont to do tenant specific configuration there should be a listener in Jaggery level. > >>> 5) Since we have one consumer key and secret if it is compromised how do >>> we revoke it? How does mobile apps adhere to this change since it stores >>> these in sandbox securely at the first time. I believe dynamic consumer >>> key/secret generation minimize this issue and it affect only to minimal set >>> of devices rather than all the devices in the system. >>> >> Yeah this limitation is there until we implement dynamic client generation. This issue has been discussed here [a] - [Dev]EMM OAuth Implementation - Android - Storing Consumer Secret. Actually we cannot take client id, client secret from server dynamically until we implement dynamic client generation. With current situation there won't be any major issue by not having auto subscribe feature. If we are really going to do this, we can discuss the architecture in a separate mail. What I want to highlight is basically API security should work in both super tenant and other tenants as well, this is nothing to do with auto publisher or auto subscriber. I will explain the issue here from the beginning EMM API manger integration has been done exactly same way as G-reg API manager integration. The first problem we faced was current APIM G-reg integration has been done by considering only root context. Since EMM APIs having sub contexts like foo/bar current implementation does not work for EMM APIs. In order to proceed the work we went ahead and made a patch detail discussion here [b]. After applying this patch our sub context problem was sorted for super tenant environment but tenanted environments we are facing some caching issues. (java.lang.SecurityException: Illegal access attempt to cache ] owned by tenant {[carbon.super],[-1234]} by tenant {[carbon.super],[1]}) even though we disable the gateway cache still the issue is there with interceptor patch. Appreciate very much if APIM team can resolve APIMANAGER-2175 <https://wso2.org/jira/browse/APIMANAGER-2175> and make it work for tenanted environment as well. [b] Exposing Oauth Protected APIs for mobile devices to EMM server communication [c] https://wso2.org/jira/browse/APIMANAGER-2175 >>> Let me know your thoughts on these. >>> >>> >>> [1] - [Dev]Securing the APIs on EMM in multi tenant environment >>> [2] - [Dev]EMM OAuth Implementation - Android - Storing Consumer Secret >>> [3] - https://docs.wso2.org/display/AM170/Publisher+APIs >>> >>> >>> Regards, >>> >>> Dilshan >>> >>> -- >>> Dilshan Edirisuriya >>> Senior Software Engineer - WSO2 >>> Mob: + 94 777878905 >>> http://wso2.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Chan (Dulitha Wijewantha) >> Software Engineer - Mobile Development >> WSO2Mobile >> Lean.Enterprise.Mobileware >> * ~Email [email protected] <[email protected]>* >> * ~Mobile +94712112165 <%2B94712112165>* >> * ~Website dulitha.me <http://dulitha.me>* >> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >> *~Github @dulichan <https://github.com/dulichan>* >> *~SO @chan <http://stackoverflow.com/users/813471/chan>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Dilshan Edirisuriya > Senior Software Engineer - WSO2 > Mob: + 94 777878905 > http://wso2.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: [email protected] Mobile: +94 (71) 8020933
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
