[feedhenry-dev] Authentication in Mobile.Next

Fri Aug 25 15:47:28 UTC 2017

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)

> * 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.)

*- 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.

*- 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?*
*What kind of level of configuration and automation team want to provide
(Should user create their realms etc.?)*
*Do we plan to enable security for our templates outside the box?*

> * Anything else around authentication?
>

Do we plan to do Authorization?

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