8:26 a.m.
Hi Bill, I’m not sure if this is planned, but don’t hurt to ask. For Aerogear we have the
following needs and I would like to help if it's planned for Keycloak (I don't
want to create overlappings)
- Data sync
Scenario: user must update the data on the server, but it must be stored encrypted.
I'm considering to generate a key pair during the "handshake" between client
and server and send client's public key to the server. In this way prevent user's
data violation.
- Unified push server
Currently the Push server requires a passphrase for iOS variants, something like (borrowed
from https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/READM...
curl -3 -v -b cookies.txt -c cookies.txt
-i -H "Accept: application/json" -H "Content-type:
multipart/form-data"
-F "certificate=(a)/Users/matzew/Desktop/MyProdCert.p12"
-F "passphrase=TopSecret"
-F "production=true" // make sure you have Production certificate and
Provisioning Profile
-X POST https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/iOS
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.
- 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?
Regarding the adapters, we could help with it for sure.
--
abstractj
On February 25, 2014 at 9:40:38 PM, Bill Burke (bburke(a)redhat.com) wrote:
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