<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 February 2014 15:42, Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Bill Burke&quot; &lt;<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>&gt;<br>
</div><div class="">&gt; To: &quot;Stian Thorgersen&quot; &lt;<a href="mailto:stian@redhat.com">stian@redhat.com</a>&gt;<br>
&gt; Cc: <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
&gt; Sent: Wednesday, 26 February, 2014 12:40:32 AM<br>
&gt; Subject: Re: [keycloak-dev] 1.0 Final roadmap<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div><div class="">&gt; On 2/25/2014 12:44 PM, Stian Thorgersen wrote:<br>
&gt; &gt; See comments in-line<br>
&gt; &gt;<br>
&gt; &gt; Mobile adapters would be really good to have. If we can get help from the<br>
&gt; &gt; AeroGear team to do these, maybe we could include this as well? For<br>
&gt; &gt; simplicity we could just aim for a working Cordova example, but Android<br>
&gt; &gt; and iOS adapters would be great.<br></div></blockquote><div><br></div><div>Sure, we could give it a trial with our iOS adapter. </div><div>Android one is not yet available.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
&gt; &gt;<br>
&gt;<br>
&gt; Unless we get a community submission for mobile adapters, this is going<br>
&gt; to have to wait as I&#39;m not sure we have time.  I also wanted Tomcat,<br>
&gt; Jetty, Node.js, and JIRA adapters too, but those I think might have to wait.<br>
&gt;<br>
&gt; &gt; It would also be nice to make Keycloak more &quot;embeddable&quot;. I&#39;d like to be<br>
&gt; &gt; able to improve how Keycloak is embedded into LiveOak, but there&#39;s also<br>
&gt; &gt; the issue around WildFly console needing to embed it. Let&#39;s have a<br>
&gt; &gt; separate thread on this, but my current (updated) thinking is to utilize<br>
&gt; &gt; RestEasy, but to remove use of servlets<br>
&gt; &gt;<br>
&gt; &gt; There&#39;s a whole bunch of JIRA issues with fix for beta1. In the effort to<br>
&gt; &gt; prune this list a bit, here&#39;s some I think we can postpone to later:<br>
&gt; &gt;<br>
&gt;<br>
&gt; I vote we keep everything in JIRA until we start running out of time,<br>
&gt; then we&#39;ll defer.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Any particular reason for June?<br>
&gt; &gt;<br>
&gt;<br>
&gt; Aerogear requirement to get us in product.  Which is a good thing. :)<br>
<br>
</div>Nice :)<br>
<div class=""><br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; We probably need a separate thread to discuss this, but it&#39;s important that<br>
&gt; &gt; users can view what applications can currently access their account and<br>
&gt; &gt; revoke access to individual apps. This means we need to know what refresh<br>
&gt; &gt; tokens are valid, and which have been revoked by a user.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Crap.  I forgot about this.  Thanks for reminding me.<br>
&gt;<br>
&gt; &gt;&gt; * Remember Me for social logins<br>
&gt; &gt;&gt; * Federation of users/credentials with LDAP/AD.  Hopefully through<br>
&gt; &gt;&gt; Picketlink.<br>
&gt; &gt;<br>
&gt; &gt; Is this really required for the first release?<br>
&gt;<br>
&gt; If we want to be considered in Middleware BU as an SSO solution, we need<br>
&gt; this.  Also will relieve some tensions with PL team hopefully if we<br>
&gt; leverage their stuff.<br>
<br>
</div>Makes sense<br>
<div class=""><br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt; * User session management.  Admin can logout a user.<br>
&gt; &gt;&gt; * Audit log.<br>
&gt; &gt;<br>
&gt; &gt; Related things we&#39;ll need are brute force protection (including max failed<br>
&gt; &gt; login attempt before locking a users account) and email notifications on<br>
&gt; &gt; certain events.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Wouldn&#39;t it be better just to add a 1 second sleep?  Checking max failed<br>
&gt; logins would require persistence per authentication.<br>
<br>
</div>I think it&#39;s something that&#39;s a hard-requirement for anyone with really strong security needs. I&#39;d assume it would be an optional feature.<br>
<br>
For audit we&#39;ll need to persist failed logins, maybe also last logins. We can piggy-back on that.<br>
<br>
Admins should be able to go to the admin console and view the recent audit logs. Users should also be able to see events related to their account.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; --<br>
&gt; Bill Burke<br>
&gt; JBoss, a division of Red Hat<br>
&gt; <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
&gt;<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div></div>