[feedhenry-dev] Authentication in Mobile.Next

Mon Aug 28 15:43:01 UTC 2017

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170828/b1c52a35/attachment.htm>