Authentication in Mobile.Next

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Authentication in Mobile.Next

Wei Li
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?
* What features/functions around authentication you should like to see in Mobile.Next, both client and cloud side?
* If you have used Keycloak before, what is your thoughts on integration with it in mobile applications?
* Anything else around authentication?

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

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Authentication in Mobile.Next

Wojciech Trocki
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 <[hidden email]> 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

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Authentication in Mobile.Next

supittma
Administrator
In reply to this post by Wei Li


On Fri, Aug 25, 2017 at 10:33 AM, Wei Li <[hidden email]> 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?

My biggest pain is integrating in various social providers in a way that is compatible and not clunky,

For a new app there is an understood Register -> Confirm Registration -> Log In -> Use the app flow.  Social providers through OAuth combine the first three steps into a single step (select the account to use), but integrating with each provider is often very time consuming.

Keycloak manages a lot of the social flow, but it does not have a native experience and falls back to OAuth 2 web flow.  It is a bad user experience (and bad for user retention) if the first thing they do after they open your app they just downloaded if they are taken out of the app to sign into a website.
 
* What features/functions around authentication you should like to see in Mobile.Next, both client and cloud side?

Better support for real time authentication events, asynchronous sessions, and WebSockets.

On the client side we need support for Native platforms in a way that doesn't rely on WebViews.  We also need better exposure of best practices because the native platform gives us more options than the cookie store in a web browser does.  For instance tokens can be kept in a biometrically sealed keystore which require the user to use a thumbprint to unlock before the app can perform an operation.  

 
* If you have used Keycloak before, what is your thoughts on integration with it in mobile applications?

Keycloak is pure magical wonderfulness for Java EE Servers and web based applications.  Outside of this there is a lot of compatibility thanks to some smart design choices, but the documentation isn't great at explaining that.  Most of my googling for how to do something in KC often turns up my own blog posts ><.  

On Android KC is only OK.  It is really missing support for using the Google account found on most devices.  You can work around this by using webviews, redirects, etc to get this information but there isn't a golden scenario.
 
* Anything else around authentication?

I feel like we are 80% there already.  We need good docs and examples for non trivial integrations.  The learning curve is really steep because the problem is really complex and requires a lot of integrations.  If we can just support a few of those with sensible defaults that are easy to change then I think we can make a lot of headway.

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

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Authentication in Mobile.Next

supittma
Administrator
It sounds like between the meeting and this thread we have some really good lines of investigation to pursue.  

If you guys are up for it, we can have a meeting tomorrow ~1430 (0930 ET)  and fill out some spikes in a jira portfolio to begin actual work. 

Ping me on this thread, IRC, or slack and I will send you a meeting invite.


On Fri, Aug 25, 2017 at 12:08 PM, Summers Pittman <[hidden email]> wrote:


On Fri, Aug 25, 2017 at 10:33 AM, Wei Li <[hidden email]> 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?

My biggest pain is integrating in various social providers in a way that is compatible and not clunky,

For a new app there is an understood Register -> Confirm Registration -> Log In -> Use the app flow.  Social providers through OAuth combine the first three steps into a single step (select the account to use), but integrating with each provider is often very time consuming.

Keycloak manages a lot of the social flow, but it does not have a native experience and falls back to OAuth 2 web flow.  It is a bad user experience (and bad for user retention) if the first thing they do after they open your app they just downloaded if they are taken out of the app to sign into a website.
 
* What features/functions around authentication you should like to see in Mobile.Next, both client and cloud side?

Better support for real time authentication events, asynchronous sessions, and WebSockets.

On the client side we need support for Native platforms in a way that doesn't rely on WebViews.  We also need better exposure of best practices because the native platform gives us more options than the cookie store in a web browser does.  For instance tokens can be kept in a biometrically sealed keystore which require the user to use a thumbprint to unlock before the app can perform an operation.  

 
* If you have used Keycloak before, what is your thoughts on integration with it in mobile applications?

Keycloak is pure magical wonderfulness for Java EE Servers and web based applications.  Outside of this there is a lot of compatibility thanks to some smart design choices, but the documentation isn't great at explaining that.  Most of my googling for how to do something in KC often turns up my own blog posts ><.  

On Android KC is only OK.  It is really missing support for using the Google account found on most devices.  You can work around this by using webviews, redirects, etc to get this information but there isn't a golden scenario.
 
* Anything else around authentication?

I feel like we are 80% there already.  We need good docs and examples for non trivial integrations.  The learning curve is really steep because the problem is really complex and requires a lot of integrations.  If we can just support a few of those with sensible defaults that are easy to change then I think we can make a lot of headway.

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

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Authentication in Mobile.Next

Wei Li
In reply to this post by Wojciech Trocki


On Fri, Aug 25, 2017 at 4:47 PM, Wojciech Trocki <[hidden email]> 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 <[hidden email]> 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

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev





--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Authentication in Mobile.Next

supittma
Administrator
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 <[hidden email]> wrote:


On Fri, Aug 25, 2017 at 4:47 PM, Wojciech Trocki <[hidden email]> 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 <[hidden email]> 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

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev





--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev