[feedhenry-dev] Authentication in Mobile.Next

Wed Aug 30 13:14:17 UTC 2017

We've made some Spikes to schedule and work out in the future based on this
thread and the meeting.

Hat tip to Craig's impromptu demo :)

https://issues.jboss.org/browse/FH-3993

On Mon, Aug 28, 2017 at 11:43 AM, Wei Li <weil at redhat.com> wrote:

>
>
> On Fri, Aug 25, 2017 at 4:47 PM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> Hi Wei
>>
>> I'm not really 'external' developer, but I'm heavily invested in that
>> area so wanted to share my thoughts.
>>
>> On Fri, Aug 25, 2017 at 3:33 PM, Wei Li <weil at redhat.com> wrote:
>>
>>> Hi FeedHenry developers,
>>>
>>> As you may have heard, we are planning on delivering a few
>>> mobile-focused services in Mobile.Next project. One of the services we are
>>> looking at is authentication.
>>>
>>> As a start, we first would like to kick off some discussions around
>>> requirements & expectations of this service within the community. More
>>> specifically, we are looking for some answers to the following questions:
>>>
>>> * What is the biggest pain point you currently have in terms of user
>>> authentication when develop mobile applications?
>>>
>>
>> *From what I have seen so far most of the problems I encountered can be
>> assigned to two categories:*
>>
>> - Legacy, custom auth in the cloud. Difficult to integrate authentication
>> with user sources.
>> -  SDK's are build with assumption that some particular security solution
>> (FH_AUTH_... headers e.g.) is being used (Lack of choices on the client)
>>
>
> Looks like these are about using the existing auth function of the
> platform. Sorry I didn't make it clear but what I am looking for here is
> not about using FH.auth, but in general - e.g. What are the pain
> points/problems when you need to implement user authentication in a mobile
> application (that may not use FH.auth/RHMAP)?
>
> FH.Auth is deprecated and we are looking at a new implementation for
> Mobile.Next.
>
>
>>
>>
>>> * What features/functions around authentication you should like to see
>>> in Mobile.Next, both client and cloud side?
>>>
>>
>> *RHMAP specific **functionalities**: *
>>
>> *- Authentication detached from SDK's *
>> For example by creating auth service (keycloak).
>> Lightweight aproach (for example using JWT in node.js server) should
>> still be possible - let's avoid hard dependency to security service.
>>
>> *- Pluggable auth*
>> Feedhenry libraries should have clear and documented path that will
>> properly explain how authentication and authorization can be added.
>>
>> *- Local setup (development)*
>> IMHO We should provide options to work when this service is not
>> provisioned (development, local setup etc.)
>>
>> *Keycloak specific functionalities (little bit outside auth area)*
>>
>> *- Preconfigured realm with "suggested security options"*
>> Create realms that will come with the best security practices.
>> This realms, may be used as template for creating some specific app type
>> (mobile, website etc.)
>>
>
> +1. I think for a non-security expert, Keycloak is not really that easy to
> use. We need to figure out something to make it as easy as possible to
> setup, or "just work". Creating/configuring sample realms sounds like a
> good approach to explore.
>
>
>>
>> *- Automatic creation of client when deploying new template (depending on
>> type)*
>> We can associate client with mobile/website template and create separate
>> one if needed.
>> This will reduce amount of boilerplate and will allow us to support
>> "default" authentication.
>> It will work nice with demos and simplify overall getting started
>> experience.
>>
>> *- Templates that promote best security patterns (PIN, secure file
>> storage, encrypted sync and work with default realm)*
>> This may not be related to auth, but I think it's best to have template
>> that will include "best security practices" and can be used as base for
>> projects.
>> Everything to improve getting started experience with Keycloak and RHMAP.
>>
>
> Yes, this is the aim of the mobile security project we are working on at
> the moment.
>
>
>>
>> *- Supporting keycloak customization (if possible)*
>> Users should be able to provide custom login page (probably requires s2i
>> build), change configuration, add user federations without breaking
>> RHMAP integration.
>> IMHO we should allow developers to configure keycloak as they wish
>> without breaking other services and that may be the challenge.
>>
>>
>>
>>> * If you have used Keycloak before, what is your thoughts on integration
>>> with it in mobile applications?
>>>
>>
>>
>> Keycloak usability depends on the platform (website, cordova, android
>> etc.).
>> Some of the functionalities may not be available on the mobile etc.
>>
>> Keycloak auth is really specific as most of their documentation and demos
>> focus on customized login page (which is website)
>>
>> The biggest pain point with keycloak IMHO is that it needs to be
>> strongly integrated with your app.
>> For example integrated keycloak is adding lots of random data into URL
>> which breaks most of the javascript frameworks that use hash routers.
>> Users lose control over the login page etc. When using token based
>> aproach this problems will disappear, but this may be difficult for
>> beginners.
>>
>> Another pain point is that to make some modifications around user
>> federations, login page and themes require physical changes in container -
>> like dropping jar.
>> It's not that this will hit our customers but it may be painful to
>> orchestrate to our service architecture.
>>
>> Another problem you may hit is that keycloak seems to be more centralized
>> single sign on solution - where companies and corporations have single
>> instance of it
>> to deal with all auth problems in organization. If we start spinning
>> multiple services we need to think about granularity and duplication of
>> user data issues that may appear.
>> You probably have all of this sorted, but wanted to mention that just in
>> case.
>>
>> IMHO the biggest challenge here is to get something generic as it will
>> mean that some particular choices will need to be made for developers.
>> Keycloak is pretty good and generic framework on his own that can be
>> setup and configured in short amount of time.
>> Most of the work required to setup keycloak will be related with actual
>> configuration (realms, groups etc.) that is hard to generalize.
>>
>> I think that I might be missing the main point here:
>> *What will be the end user value or set of technical problems team want
>> to resolve by having Keycloak service over the standard keycloak template
>> deployed to OpenShift?*
>>
>
> It probably will be the same Keycloak, but optimised for mobile
> applications. In my view, the ideal scenario would be that a developer
> enables the service, no configuration required, just download the
> configuration file, add the client side library into the mobile application
> and done.  For all the other services, the request authentications are
> handled automatically.
>
> There might be some other configurations that they can change, but those
> should be well documented, and the users don't need to know Keycloak if
> they don't want to.
>
>
>> *What kind of level of configuration and automation team want to provide
>> (Should user create their realms etc.?)*
>>
>
> In my view, as much as we can to the point where it will just work by
> default.
>
>
>> *Do we plan to enable security for our templates outside the box?*
>>
>
> Are we still talking about client templates? There will be some templates
> dedicated to demonstrate the best security practices, and hopefully all the
> templates will have some degree of security elements in them.
>
>
>>
>>
>>> * Anything else around authentication?
>>>
>>
>> Do we plan to do Authorization?
>>
>>
>
> I would say yes, but that's another discussion.
>
>
>>
>>> The answers to those questions will help us make sure we deliver
>>> something that will solve the problems you are facing day to day.
>>>
>>> We look forward to your answers and thank you in advance.
>>>
>>> Regards,
>>>
>>> --
>>>
>>> WEI LI
>>>
>>> SENIOR SOFTWARE ENGINEER
>>>
>>> Red Hat Mobile <https://www.redhat.com/>
>>>
>>> weil at redhat.com    M: +353862393272
>>> <https://red.ht/sig>
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>
>
> --
>
> WEI LI
>
> SENIOR SOFTWARE ENGINEER
>
> Red Hat Mobile <https://www.redhat.com/>
>
> weil at redhat.com    M: +353862393272
> <https://red.ht/sig>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170830/559ad4c9/attachment.htm>