8:29 p.m.
I'd like to do another release in February. Let's get an idea on
available resources, what the priority are, and who can work on what.
Let's see what work we can do in parallel.
Key functionality:
* Get Stan's Wildfly subsystem incorporated.
* Figure out appropriate addition to admin console for Stan's subsystem.
An SPI or something as well as UI.
* Composite Roles.
* Clean up Forgot Password and Reset password. Should be possible for
admin to send user an email with a URL that allows them to reset the
password. Right now requires entering in a password, telling user, and
sending an email.
* Password Policies are broken.
* Revocation policies.
* Storage protection. Smarter password hashes and protection of private
keys and OTP keys.
* User session management. Be able to show and list users logged into
an app and be able to remotely logout one or all of them.
* More CORS options at the adapter level.
* Device mgmt and security. Need input from Bruno.
Basically, we should have laser focus on critical features that must be
implemented to have a functional Keycloak release, but also to support
the needs of Red Hat projects specifically LiveOak, Wildfly, and
Aerogear. Having Keycloak drive security for those 3 projects will get
us a lot more users than if we just went at it alone.
Personally, I'd like to get Stan's work incorporated as soon as possible
and figure out a UI around it. We should brainstorm together, but I
think we may have to rethink some of our UI.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:03 a.m.
+1 To all of those, especially the WildFly sub-system
I've got some more stuff:
Features for LiveOak:
* Mongo store - this would be the default used in LiveOak
* Theme support for forms - I've got an idea how this will work and I'll send out
an email about it next week
General features:
* Audit - at least audit basic events for now. Start with a basic audit spi, and a log
based impl? Console, read, notifications, db, etc can come later.
* Security review - we should have a security review of code/features
* Code de-crapping - there's smelly code and duplicated code, time for some
refactoring? Personally I'd like to see the code improved, but I don't want to
spend weeks re-learning the code base either. A good approach would be to identify the
biggest pain points, discuss a solution, refactor, then once refactored send out a summary
email covering the changes
* Export/import - support dumping all data to a single json file. This will be useful for
migrating db between versions, moving to a different store, backup, etc..
* Data migration plan - new releases will have new db schemas. A nice and simple approach
to this is to use the export/import feature. We can have a pipeline that can converts a
json export from version 1, to version 2, to version 3, etc..
* HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we should be able to
pull this in with minimum effort
* Application/client types (service, public, mobile, ?) - there's a few things that
are different depending on the client type. For example a public client (i.e. html5) are
required to set a valid redirect_uri and doesn't require a password, while for a
private client (i.e. rest service) redirect_uri is optional and password required
* Extend testsuite - add more tests to the testsuite, especially it would be great to see
some tests for the admin console
* JPA db - test on production dbs (postgresql, mysql, do we even bother with oracle?)
Some comments in-line as well.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Friday, 24 January, 2014 2:29:26 AM
Subject: [keycloak-dev] priorities and who is available?
I'd like to do another release in February. Let's get an idea on
available resources, what the priority are, and who can work on what.
Let's see what work we can do in parallel.
Key functionality:
* Get Stan's Wildfly subsystem incorporated.
* Figure out appropriate addition to admin console for Stan's subsystem.
An SPI or something as well as UI.
* Composite Roles.
* Clean up Forgot Password and Reset password. Should be possible for
admin to send user an email with a URL that allows them to reset the
password. Right now requires entering in a password, telling user, and
sending an email.
I assume you're only talking about when an admin resets the password on-behalf of the
user?
It should be simple enough to add a button to let an admin send a password reset link to a
user as we already have that functionality for the user themselves. It's that what you
want? We still need the option of being able to set a temp password in case the user
doesn't have a email registered (or emails can't be used for whatever reason).
* Password Policies are broken.
I'll get the ball started on the next release and fix that once I've finished
writing this mail ;)
* Revocation policies.
* Storage protection. Smarter password hashes and protection of private
keys and OTP keys.
* User session management. Be able to show and list users logged into
an app and be able to remotely logout one or all of them.
* More CORS options at the adapter level.
* Device mgmt and security. Need input from Bruno.
Basically, we should have laser focus on critical features that must be
implemented to have a functional Keycloak release, but also to support
the needs of Red Hat projects specifically LiveOak, Wildfly, and
Aerogear. Having Keycloak drive security for those 3 projects will get
us a lot more users than if we just went at it alone.
Personally, I'd like to get Stan's work incorporated as soon as possible
and figure out a UI around it. We should brainstorm together, but I
think we may have to rethink some of our UI.
--
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
6:50 a.m.
Good morning Stian, on AeroGear we had a discussion about how to properly reset passwords
and we have too much to improve, but here comes my 2 cents.
--
abstractj
On January 24, 2014 at 8:03:08 AM, Stian Thorgersen (stian(a)redhat.com) wrote:
> Some comments in-line as well.
----- Original Message -----
I assume you're only talking about when an admin resets the password
on-behalf of the user?
It should be simple enough to add a button to let an admin send a
password reset link to a user as we already have that functionality
for the user themselves. It's that what you want? We still need
the option of being able to set a temp password in case the user
doesn't have a email registered (or emails can't be used for whatever
reason).
What concerns me about this approach is the fact that once the admin account is
compromised, is possible to reset everyone’s account even if you don’t have access do the
database. If users doesn’t have e-mail registered, maybe we could evaluate another
confirmation method? Maybe TOTP?
7:41 a.m.
It would be interesting to customise the UI with new colours / logo since the current
style is supposed to be used for products.
Also, please let me know if we need to improve / create new stuff for the UI.
Gabriel
On Jan 24, 2014, at 10:50 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good morning Stian, on AeroGear we had a discussion about how to
properly reset passwords and we have too much to improve, but here comes my 2 cents.
--
abstractj
On January 24, 2014 at 8:03:08 AM, Stian Thorgersen (stian(a)redhat.com) wrote:
>> Some comments in-line as well.
>
> ----- Original Message -----
>
> I assume you're only talking about when an admin resets the password
> on-behalf of the user?
>
> It should be simple enough to add a button to let an admin send a
> password reset link to a user as we already have that functionality
> for the user themselves. It's that what you want? We still need
> the option of being able to set a temp password in case the user
> doesn't have a email registered (or emails can't be used for whatever
> reason).
What concerns me about this approach is the fact that once the admin account is
compromised, is possible to reset everyone’s account even if you don’t have access do the
database. If users doesn’t have e-mail registered, maybe we could evaluate another
confirmation method? Maybe TOTP?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
---
Gabriel Cardoso
User Experience Designer @ Red Hat
8:32 a.m.
All good stuff. I'm thinking maybe we all pick one major feature we all
can work on. Pick a date. Whatever is done by that date is what gets in
that release.
On 1/24/2014 5:03 AM, Stian Thorgersen wrote:
+1 To all of those, especially the WildFly sub-system
I've got some more stuff:
Features for LiveOak:
* Mongo store - this would be the default used in LiveOak
I don't understand your fascination with kiddie DBs. ;)
* HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we should be able to
pull this in with minimum effort
We can build on this for a Node.js adapter too.
* Application/client types (service, public, mobile, ?) - there's
a few things that are different depending on the client type. For example a public client
(i.e. html5) are required to set a valid redirect_uri and doesn't require a password,
while for a private client (i.e. rest service) redirect_uri is optional and password
required
For mobile clients, I'm also thinking all they need is a refresh token.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:38 a.m.
Alpha2 released by end of Feb?
I'll do form themes. Marek can work on Mongo store.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 24 January, 2014 2:32:41 PM
Subject: Re: [keycloak-dev] priorities and who is available?
All good stuff. I'm thinking maybe we all pick one major feature we all
can work on. Pick a date. Whatever is done by that date is what gets in
that release.
On 1/24/2014 5:03 AM, Stian Thorgersen wrote:
> +1 To all of those, especially the WildFly sub-system
>
> I've got some more stuff:
>
> Features for LiveOak:
>
> * Mongo store - this would be the default used in LiveOak
I don't understand your fascination with kiddie DBs. ;)
>
> * HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we
> should be able to pull this in with minimum effort
We can build on this for a Node.js adapter too.
> * Application/client types (service, public, mobile, ?) - there's a few
> things that are different depending on the client type. For example a
> public client (i.e. html5) are required to set a valid redirect_uri and
> doesn't require a password, while for a private client (i.e. rest service)
> redirect_uri is optional and password required
For mobile clients, I'm also thinking all they need is a refresh token.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:38 a.m.
Good morning, if nobody is planning to work on it, I can work on storage protection and
help to define the device mgmt stuff, just let me know about which date or period (mid
Feb, end Feb...) do you want to release it.
--
abstractj
On January 24, 2014 at 12:29:27 AM, Bill Burke (bburke(a)redhat.com) wrote:
> * Storage protection. Smarter password hashes and protection
of private
keys and OTP keys.
* User session management. Be able to show and list users logged
into
an app and be able to remotely logout one or all of them.
* More CORS options at the adapter level.
* Device mgmt and security. Need input from Bruno.
8:12 a.m.
Give me until the end of next week to get the subsystem cleaned up and
ready to merge. I want to get it fully working end to end before I turn
it over. After that, I'll see how much time I can allocate to help.
Stan
On 1/23/2014 9:29 PM, Bill Burke wrote:
I'd like to do another release in February. Let's get an
idea on
available resources, what the priority are, and who can work on what.
Let's see what work we can do in parallel.
Key functionality:
* Get Stan's Wildfly subsystem incorporated.
* Figure out appropriate addition to admin console for Stan's subsystem.
An SPI or something as well as UI.
* Composite Roles.
* Clean up Forgot Password and Reset password. Should be possible for
admin to send user an email with a URL that allows them to reset the
password. Right now requires entering in a password, telling user, and
sending an email.
* Password Policies are broken.
* Revocation policies.
* Storage protection. Smarter password hashes and protection of private
keys and OTP keys.
* User session management. Be able to show and list users logged into
an app and be able to remotely logout one or all of them.
* More CORS options at the adapter level.
* Device mgmt and security. Need input from Bruno.
Basically, we should have laser focus on critical features that must be
implemented to have a functional Keycloak release, but also to support
the needs of Red Hat projects specifically LiveOak, Wildfly, and
Aerogear. Having Keycloak drive security for those 3 projects will get
us a lot more users than if we just went at it alone.
Personally, I'd like to get Stan's work incorporated as soon as possible
and figure out a UI around it. We should brainstorm together, but I
think we may have to rethink some of our UI.
8:36 a.m.
There is one potential roadblock to adding UI for the KeyCloak subsystem
right now. When you put the UI into the KeyCloak console you won't be
able to directly access the http management endpoint. This is a
limitation that is being addressed by Darran's work on CORS support.
Darran, would it be possible to get a fork of the latest WildFly that
just allows all CORS requests. Is that something you could do without
much effort so we would have a build that we could use for development?
Herald Pehl created a fork like that, but it is based on WildFly 8 Alpha
1, which doesn't work with KeyCloak.
http://hpehl.info/independent-jboss-admin-console.html
On 1/24/2014 9:12 AM, ssilvert(a)redhat.com wrote:
Give me until the end of next week to get the subsystem cleaned up
and
ready to merge. I want to get it fully working end to end before I turn
it over. After that, I'll see how much time I can allocate to help.
Stan
On 1/23/2014 9:29 PM, Bill Burke wrote:
> I'd like to do another release in February. Let's get an idea on
> available resources, what the priority are, and who can work on what.
> Let's see what work we can do in parallel.
>
> Key functionality:
>
> * Get Stan's Wildfly subsystem incorporated.
> * Figure out appropriate addition to admin console for Stan's subsystem.
> An SPI or something as well as UI.
> * Composite Roles.
> * Clean up Forgot Password and Reset password. Should be possible for
> admin to send user an email with a URL that allows them to reset the
> password. Right now requires entering in a password, telling user, and
> sending an email.
> * Password Policies are broken.
> * Revocation policies.
> * Storage protection. Smarter password hashes and protection of private
> keys and OTP keys.
> * User session management. Be able to show and list users logged into
> an app and be able to remotely logout one or all of them.
> * More CORS options at the adapter level.
> * Device mgmt and security. Need input from Bruno.
>
> Basically, we should have laser focus on critical features that must be
> implemented to have a functional Keycloak release, but also to support
> the needs of Red Hat projects specifically LiveOak, Wildfly, and
> Aerogear. Having Keycloak drive security for those 3 projects will get
> us a lot more users than if we just went at it alone.
>
> Personally, I'd like to get Stan's work incorporated as soon as possible
> and figure out a UI around it. We should brainstorm together, but I
> think we may have to rethink some of our UI.
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:59 a.m.
I will have to see if I can get a chance next week, since we moved to
Undertow our CORS handling is also in the wrong location!
Regards,
Darran Lofthouse.
On 24/01/14 14:36, ssilvert(a)redhat.com wrote:
There is one potential roadblock to adding UI for the KeyCloak
subsystem
right now. When you put the UI into the KeyCloak console you won't be
able to directly access the http management endpoint. This is a
limitation that is being addressed by Darran's work on CORS support.
Darran, would it be possible to get a fork of the latest WildFly that
just allows all CORS requests. Is that something you could do without
much effort so we would have a build that we could use for development?
Herald Pehl created a fork like that, but it is based on WildFly 8 Alpha
1, which doesn't work with KeyCloak.
http://hpehl.info/independent-jboss-admin-console.html
On 1/24/2014 9:12 AM, ssilvert(a)redhat.com wrote:
> Give me until the end of next week to get the subsystem cleaned up and
> ready to merge. I want to get it fully working end to end before I turn
> it over. After that, I'll see how much time I can allocate to help.
>
> Stan
>
> On 1/23/2014 9:29 PM, Bill Burke wrote:
>> I'd like to do another release in February. Let's get an idea on
>> available resources, what the priority are, and who can work on what.
>> Let's see what work we can do in parallel.
>>
>> Key functionality:
>>
>> * Get Stan's Wildfly subsystem incorporated.
>> * Figure out appropriate addition to admin console for Stan's subsystem.
>> An SPI or something as well as UI.
>> * Composite Roles.
>> * Clean up Forgot Password and Reset password. Should be possible for
>> admin to send user an email with a URL that allows them to reset the
>> password. Right now requires entering in a password, telling user, and
>> sending an email.
>> * Password Policies are broken.
>> * Revocation policies.
>> * Storage protection. Smarter password hashes and protection of private
>> keys and OTP keys.
>> * User session management. Be able to show and list users logged into
>> an app and be able to remotely logout one or all of them.
>> * More CORS options at the adapter level.
>> * Device mgmt and security. Need input from Bruno.
>>
>> Basically, we should have laser focus on critical features that must be
>> implemented to have a functional Keycloak release, but also to support
>> the needs of Red Hat projects specifically LiveOak, Wildfly, and
>> Aerogear. Having Keycloak drive security for those 3 projects will get
>> us a lot more users than if we just went at it alone.
>>
>> Personally, I'd like to get Stan's work incorporated as soon as possible
>> and figure out a UI around it. We should brainstorm together, but I
>> think we may have to rethink some of our UI.
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
4367
days inactive
4367
days old
9 comments
6 participants
participants (6)
-
Bill Burke -
Bruno Oliveira -
Darran Lofthouse -
Gabriel Cardoso -
ssilvert＠redhat.com -
Stian Thorgersen