<div dir="ltr"><div>We've made some Spikes to schedule and work out in the future based on this thread and the meeting.</div><div><br></div><div>Hat tip to Craig's impromptu demo :)</div><div><br></div><a href="https://issues.jboss.org/browse/FH-3993">https://issues.jboss.org/browse/FH-3993</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 28, 2017 at 11:43 AM, Wei Li <span dir="ltr"><<a href="mailto:weil@redhat.com" target="_blank">weil@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Aug 25, 2017 at 4:47 PM, Wojciech Trocki <span dir="ltr"><<a href="mailto:wtrocki@redhat.com" target="_blank">wtrocki@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="m_1268659381742576779m_8084486352608167190gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><font color="#0000ff">Hi Wei</font></div><div><br><font color="#0000ff">I'm not really 'external' developer, but I'm heavily invested in that area so wanted to share my thoughts.</font></div></div></div></div></div></div></div>
<br><div class="gmail_quote"><span>On Fri, Aug 25, 2017 at 3:33 PM, Wei Li <span dir="ltr"><<a href="mailto:weil@redhat.com" target="_blank">weil@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi FeedHenry developers,<div><br></div><div>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. </div><div><br></div><div>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:</div><div><br></div><div>* What is the biggest pain point you currently have in terms of user authentication when develop mobile applications?</div></div></blockquote></span><div><font color="#0000ff"><br><i><b>From what I have seen so far most of the problems I encountered can be assigned to two categories:</b></i></font></div><div><i><b><font color="#0000ff"><br></font></b></i></div><div><font color="#0000ff">- Legacy, custom auth in the cloud. Difficult to integrate authentication with user sources. <br></font></div><div><font color="#0000ff">-  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)</font></div></div></div></div></blockquote><div><br></div></span><div>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)?</div><div><br></div><div>FH.Auth is deprecated and we are looking at a new implementation for Mobile.Next.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* What features/functions around authentication you should like to see in Mobile.Next, both client and cloud side?</div></div></blockquote><div><br></div></span><div><font size="4" color="#0000ff"><b>RHMAP specific </b><b>functionalities</b><b>: </b></font></div><div><font color="#0000ff"><br><b>- Authentication detached from SDK's </b></font></div><div><font color="#0000ff">For example by creating auth service (keycloak).</font></div><div><font color="#0000ff">Lightweight aproach (for example using JWT in node.js server) should still be possible - let's avoid hard dependency to security service.</font></div><div><br></div><div><font color="#0000ff"><b>- Pluggable auth</b></font></div><div><font color="#0000ff">Feedhenry libraries should have clear and documented path that will properly explain how authentication and authorization can be added.</font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff"><b>- Local setup (development)</b></font></div><div><span style="color:rgb(0,0,255)">IMHO We should provide options to work when this service is not provisioned (development, local setup etc.)</span><font color="#0000ff"><br></font></div><div><b><font color="#0000ff"><br></font></b></div><div><b><font size="4" color="#0000ff">Keycloak specific functionalities (little bit outside auth area)</font></b></div><div><b><font color="#0000ff"><br></font></b></div><div><font color="#0000ff"><b>- Preconfigured realm with "suggested security options"</b><br>Create realms that will come with the best security practices. <br>This realms, may be used as template for creating some specific app type (mobile, website etc.) </font></div></div></div></div></blockquote><div><br></div></span><div>+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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><b><font color="#0000ff"><br></font></b></div><div><b><font color="#0000ff">- Automatic creation of client when deploying new template (depending on type)</font></b></div><div><font color="#0000ff">We can associate client with mobile/website template and create separate one if needed. <br>This will reduce amount of boilerplate and will allow us to support "default" authentication.<br>It will work nice with demos and simplify overall getting started experience.</font></div><div><b><font color="#0000ff"><br></font></b></div><div><b><font color="#0000ff">- Templates that promote best security patterns (PIN, secure file storage, encrypted sync and work with default realm)</font></b></div><div><font color="#0000ff">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.<br>Everything to improve getting started experience with Keycloak and RHMAP.</font></div></div></div></div></blockquote><div><br></div></span><div>Yes, this is the aim of the mobile security project we are working on at the moment.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><b><font color="#0000ff"><br></font></b></div><div><b><font color="#0000ff">- Supporting keycloak customization (if possible)</font></b></div><div><font color="#0000ff">Users should be able to provide custom login page (probably requires s2i build), change configuration, </font><span style="color:rgb(0,0,255)">add user federations without breaking RHMAP integration. </span></div><div><font color="#0000ff">IMHO we should allow developers to configure keycloak as they wish without breaking other services </font><span style="color:rgb(0,0,255)">and that may be the challenge.</span></div><span><div><b><br></b></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* If you have used Keycloak before, what is your thoughts on integration with it in mobile applications?</div></div></blockquote><div><br></div><div><br></div></span><div><font color="#0000ff">Keycloak usability depends on the platform (website, cordova, android etc.). </font></div><div><font color="#0000ff">Some of the functionalities may not be available on the mobile etc.</font></div><div><font color="#0000ff"><br>Keycloak auth is really specific as most of their documentation and demos focus on customized login page (which is website)</font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">The biggest pain point with keycloak IMHO is that it needs to be strongly integrated with your app. </font></div><div><font color="#0000ff">For example integrated keycloak is adding lots of random data into URL which breaks most of the javascript frameworks that use hash routers.<br>Users lose control over the login page etc. When using token based aproach this problems will disappear, but this may be difficult for beginners.</font></div><div><font color="#0000ff"><br>Another pain point is that to make some modifications around user federations, login page and themes require physical changes in container - like dropping jar.</font></div><div><font color="#0000ff">It's not that this will hit our customers but it may be painful to orchestrate to our service architecture.<br><br>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 </font></div><div><font color="#0000ff">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.</font></div><div><font color="#0000ff">You probably have all of this sorted, but wanted to mention that just in case.<br></font></div><div><br></div><div><font color="#0000ff">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.</font></div><div><font color="#0000ff">Keycloak is pretty good and generic framework on his own that can be setup and configured in short amount of time. <br>Most of the work required to setup keycloak will be related with actual configuration (realms, groups etc.) that is hard to generalize.</font></div><div><br></div><div><font color="#0000ff">I think that I might be missing the main point here:  </font></div><div><span style="color:rgb(0,0,255)"><b>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?</b></span></div></div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="color:rgb(0,0,255)"><b>What kind of level of configuration and automation team want to provide (Should user create their realms etc.?)</b></span></div></div></div></div></blockquote><div><br></div></span><div>In my view, as much as we can to the point where it will just work by default.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="color:rgb(0,0,255)"><b>Do we plan to enable security for our templates outside the box?</b></span></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><font color="#0000ff"> </font><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* Anything else around authentication?</div></div></blockquote></span><div><br><font color="#0000ff">Do we plan to do Authorization?</font></div><div> </div></div></div></div></blockquote><div><br></div></span><div>I would say yes, but that's another discussion.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir="ltr"><div><br></div><div>The answers to those questions will help us make sure we deliver something that will solve the problems you are facing day to day. </div><div><br></div><div>We look forward to your answers and thank you in advance.</div><div><br></div><div>Regards,</div><span class="m_1268659381742576779m_8084486352608167190gmail-HOEnZb"><font color="#888888"><div><div><br></div>-- <br><div class="m_1268659381742576779m_8084486352608167190gmail-m_2902577191550105321gmail_signature"><div dir="ltr"><div><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>WEI</span> <span>LI</span></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>SENIOR SOFTWARE ENGINEER</span></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat <span>Mobile</span></a></p><p style="font-family:overpass,sans-serif;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"><a href="mailto:weil@redhat.com" style="color:rgb(0,136,206);margin:0px" target="_blank">weil@redhat.com</a>   </span> <span>M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272</a>    </span></p><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img width="90" height="auto"></a></td></tr></tbody></table></div></div></div></div>
</div></font></span></div>
<br></span>______________________________<wbr>_________________<br>
feedhenry-dev mailing list<br>
<a href="mailto:feedhenry-dev@redhat.com" target="_blank">feedhenry-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/feedhenry-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></span></div><span class=""><br><br clear="all"><div><br></div>-- <br><div class="m_1268659381742576779gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>WEI</span> <span>LI</span></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>SENIOR SOFTWARE ENGINEER</span></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat <span>Mobile</span></a></p><p style="font-family:overpass,sans-serif;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"><a href="mailto:weil@redhat.com" style="color:rgb(0,136,206);margin:0px" target="_blank">weil@redhat.com</a>   </span> <span>M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272</a>    </span></p><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img width="90" height="auto"></a></td></tr></tbody></table></div></div></div></div>
</span></div></div>
<br>______________________________<wbr>_________________<br>
feedhenry-dev mailing list<br>
<a href="mailto:feedhenry-dev@redhat.com">feedhenry-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/feedhenry-dev</a><br>
<br></blockquote></div><br></div>