From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 25 February, 2014 4:51:44 PM Subject: [keycloak-dev] 1.0 Final roadmap What's left for must-have features before we can start pushing for a 1.0.Final release? We need to release 1.0 sometime in June.

* Minimal OpenID Connect support * Import/Export of various items of a realm (for data migration). * Aerogear bootstrap requirements * Theme support for admin console so we can brand it. * Revocation policies. I'm thinking Not-Before is good enough for a 1.0 release. We need to be able to push this to deployed apps. And also maybe piggyback this information in AcessTokenResponse. This also of course needs to be stored within subsystem config too, or maybe we could just have adapters pull that information from server at bootup.

* Remember Me for social logins * Federation of users/credentials with LDAP/AD. Hopefully through Picketlink.

* User session management. Admin can logout a user. * Audit log.

Scaling/Optimization: * Storage cache for the token service so it doesn't hit the database. * Make token service stateless for clustering environments (maybe don't need for 1.0?) We'll stick with only AS7/EAP/Wildfly adapters for 1st release. We also have to pencil in time for weeks of test writing, benchmarking, and documentation. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Matthias Wessendorf" <matzew(a)apache.org&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Tuesday, 25 February, 2014 5:57:02 PM Subject: Re: [keycloak-dev] 1.0 Final roadmap On Tuesday, February 25, 2014, Stian Thorgersen <stian(a)redhat.com&gt; wrote: > See comments in-line > > Mobile adapters would be really good to have. If we can get help from the > AeroGear team to do these, maybe we could include this as well? For > simplicity we could just aim for a working Cordova example, but Android and > iOS adapters would be great. We have OAuth2 (JS/iOS - Android coming). Could give that a shot;

-Matthias > > It would also be nice to make Keycloak more "embeddable". I'd like to be > able to improve how Keycloak is embedded into LiveOak, but there's also the > issue around WildFly console needing to embed it. Let's have a separate > thread on this, but my current (updated) thinking is to utilize RestEasy, > but to remove use of servlets > > There's a whole bunch of JIRA issues with fix for beta1. In the effort to > prune this list a bit, here's some I think we can postpone to later: > > KEYCLOAK-313 Manage devices > KEYCLOAK-311 Custom user profiles > KEYCLOAK-310 SPI for multi-factor authentication > KEYCLOAK-308 Cordova adapter > KEYCLOAK-307 iPhone adapter > KEYCLOAK-306 Android adapter > KEYCLOAK-301 Internationalization support > KEYCLOAK-300 Auto configuration of MySQL or PostgreSQL in OpenShift > cartridge > KEYCLOAK-266 Integrated help in admin console > KEYCLOAK-265 Optional instructions to social providers > KEYCLOAK-242 Add remember machine option for two factor authentication > KEYCLOAK-182 List applications on account management > KEYCLOAK-161 Allow users to create oauth clients through account pages > KEYCLOAK-57 Mobile example application > > ----- Original Message ----- > > From: "Bill Burke" <bburke(a)redhat.com <javascript:;>> > > To: keycloak-dev(a)lists.jboss.org <javascript:;> > > Sent: Tuesday, 25 February, 2014 4:51:44 PM > > Subject: [keycloak-dev] 1.0 Final roadmap > > > > What's left for must-have features before we can start pushing for a > > 1.0.Final release? We need to release 1.0 sometime in June. > > Any particular reason for June? > > > > > * Minimal OpenID Connect support > > * Import/Export of various items of a realm (for data migration). > > * Aerogear bootstrap requirements > > * Theme support for admin console so we can brand it. > > * Revocation policies. I'm thinking Not-Before is good enough for a 1.0 > > release. We need to be able to push this to deployed apps. And also > > maybe piggyback this information in AcessTokenResponse. This also of > > course needs to be stored within subsystem config too, or maybe we could > > just have adapters pull that information from server at bootup. > > We probably need a separate thread to discuss this, but it's important > that users can view what applications can currently access their account > and revoke access to individual apps. This means we need to know what > refresh tokens are valid, and which have been revoked by a user. > > > * Remember Me for social logins > > * Federation of users/credentials with LDAP/AD. Hopefully through > > Picketlink. > > Is this really required for the first release? > > > * User session management. Admin can logout a user. > > * Audit log. > > Related things we'll need are brute force protection (including max failed > login attempt before locking a users account) and email notifications on > certain events. > > > > > > > Scaling/Optimization: > > > > * Storage cache for the token service so it doesn't hit the database. > > * Make token service stateless for clustering environments (maybe don't > > need for 1.0?) > > > > > > We'll stick with only AS7/EAP/Wildfly adapters for 1st release. We also > > have to pencil in time for weeks of test writing, benchmarking, and > > documentation. > > > > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org <javascript:;> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <javascript:;> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Sent from Gmail Mobile

On 2/25/2014 12:44 PM, Stian Thorgersen wrote: > See comments in-line > > Mobile adapters would be really good to have. If we can get help from the AeroGear team to do these, maybe we could include this as well? For simplicity we could just aim for a working Cordova example, but Android and iOS adapters would be great. > Unless we get a community submission for mobile adapters, this is going to have to wait as I'm not sure we have time. I also wanted Tomcat, Jetty, Node.js, and JIRA adapters too, but those I think might have to wait. > It would also be nice to make Keycloak more "embeddable". I'd like to be able to improve how Keycloak is embedded into LiveOak, but there's also the issue around WildFly console needing to embed it. Let's have a separate thread on this, but my current (updated) thinking is to utilize RestEasy, but to remove use of servlets > > There's a whole bunch of JIRA issues with fix for beta1. In the effort to prune this list a bit, here's some I think we can postpone to later: > I vote we keep everything in JIRA until we start running out of time, then we'll defer. > > Any particular reason for June? > Aerogear requirement to get us in product. Which is a good thing. :) > > We probably need a separate thread to discuss this, but it's important that users can view what applications can currently access their account and revoke access to individual apps. This means we need to know what refresh tokens are valid, and which have been revoked by a user. > Crap. I forgot about this. Thanks for reminding me. >> * Remember Me for social logins >> * Federation of users/credentials with LDAP/AD. Hopefully through >> Picketlink. > > Is this really required for the first release? If we want to be considered in Middleware BU as an SSO solution, we need this. Also will relieve some tensions with PL team hopefully if we leverage their stuff. > >> * User session management. Admin can logout a user. >> * Audit log. > > Related things we'll need are brute force protection (including max failed login attempt before locking a users account) and email notifications on certain events. > Wouldn't it be better just to add a 1 second sleep? Checking max failed logins would require persistence per authentication. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Does the keypair belong to the user? Currently I'm implementing OpenID Connect's IDToken and having a screen that can say which ID "claims" an application or oauth client is allowed to view. We could add custom user attributes and the ability to request a claim for them.

> - Unified push server > > The passphrase is sent over the wire in raw text because that's required by Apple (thanks Apple). To prevent exposing user's passphrase. I was wondering about a key agreement to stabilish a shared secret between client/server, into this way the client could send that passphrase encrypted and the server decrypts it on the fly to send push messages. > > Do you guys have something similar like that, planned? Or totally out of the scope? I could help. > See above.

> - Legacy authentication > > Currently we have basic/digest supported on the client side (yep, they are pretty much unsafe, but, legacies...). Is it something planned to be supported on Keycloak? What would be the alternatives? > Not sure how Keycloak fits with basic/digest protocols. You want the application to handle login input and just delegate to Keycloak like you would any other JBoss/Wildfly security domain? We could provide that feature, but then you end up with not using 90% of Keycloak's features. Is that what you mean?

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 26 February, 2014 12:40:32 AM > Subject: Re: [keycloak-dev] 1.0 Final roadmap > > > > On 2/25/2014 12:44 PM, Stian Thorgersen wrote: > > See comments in-line > > > > Mobile adapters would be really good to have. If we can get help from the > > AeroGear team to do these, maybe we could include this as well? For > > simplicity we could just aim for a working Cordova example, but Android > > and iOS adapters would be great.

> > > > Unless we get a community submission for mobile adapters, this is going > to have to wait as I'm not sure we have time. I also wanted Tomcat, > Jetty, Node.js, and JIRA adapters too, but those I think might have to wait. > > > It would also be nice to make Keycloak more "embeddable". I'd like to be > > able to improve how Keycloak is embedded into LiveOak, but there's also > > the issue around WildFly console needing to embed it. Let's have a > > separate thread on this, but my current (updated) thinking is to utilize > > RestEasy, but to remove use of servlets > > > > There's a whole bunch of JIRA issues with fix for beta1. In the effort to > > prune this list a bit, here's some I think we can postpone to later: > > > > I vote we keep everything in JIRA until we start running out of time, > then we'll defer. > > > > > Any particular reason for June? > > > > Aerogear requirement to get us in product. Which is a good thing. :) Nice :) > > > > > We probably need a separate thread to discuss this, but it's important that > > users can view what applications can currently access their account and > > revoke access to individual apps. This means we need to know what refresh > > tokens are valid, and which have been revoked by a user. > > > > Crap. I forgot about this. Thanks for reminding me. > > >> * Remember Me for social logins > >> * Federation of users/credentials with LDAP/AD. Hopefully through > >> Picketlink. > > > > Is this really required for the first release? > > If we want to be considered in Middleware BU as an SSO solution, we need > this. Also will relieve some tensions with PL team hopefully if we > leverage their stuff. Makes sense > > > > >> * User session management. Admin can logout a user. > >> * Audit log. > > > > Related things we'll need are brute force protection (including max failed > > login attempt before locking a users account) and email notifications on > > certain events. > > > > Wouldn't it be better just to add a 1 second sleep? Checking max failed > logins would require persistence per authentication. I think it's something that's a hard-requirement for anyone with really strong security needs. I'd assume it would be an optional feature. For audit we'll need to persist failed logins, maybe also last logins. We can piggy-back on that. 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. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

> That would be great - let me know if you have any problems and I'll fix asap Any rough idea when an Android one would be available?