Separate Maven for PicketLink and MongoDB
by Stian Thorgersen
I propose that we move the adapters for PicketLink and MongoDB into separate Maven modules. IMO the code in services is already a bit crowded, and with the addition of a MongoDB implementation it will only get worse. If we add a SPI for these it would be easier in the future to add more. It would also be possible for users to write their own if they really need to.
This will also make it possible for us to release M1 with either PicketLink or MongoDB even if the non-default implementation is not fully working at the time.
13 years
application configuration idea
by Bill Burke
This is what an application configuration file looks like:
{
"realm" : "demo",
"resource" : "product-portal",
"realm-public-key" : "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADC",
"auth-url" :
"http://localhost:8080/auth-server/rest/realms/demo/tokens/login",
"code-url" :
"http://localhost:8080/auth-server/rest/realms/demo/tokens/access/codes",
"ssl-not-required" : true,
"credentials" : {
"password" : "password"
}
}
Notice that the credentials are in clear text. Admins will dislike this
tremendously. What I propose is that you must obtain the application
configuration file from the admin console. The configuration file would
be encrypted using a hash of a password specific to the application.
THe config file would then look something like this:
{
"realm" : "demo",
"encryptedConfig" : "MIGMA0GCSqGS..."
}
Then, your server instance must be booted up via a system property or
environment variable, i.e.:
standalone.sh -Dkeycloak.myrealm.password=geheim
The keycloak plugin would then decrypt the application config file based
on this password.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
provisioning/bootstrapping/installing Keycloak
by Bill Burke
How will Keycloak be provisioned, bootstrapped, configured?
How will Keycloak look the first time somebody uses it?
This are the questions I need answers to.
We discussed earlier that a SaaS for identity is probably not a good
idea. For both security and performance reasons, Keycloak should not
support multitenancy between multiple accounts. For a cloud
environment, we will instead deploy Keycloak as a cartridge for a
specific Openshift account.
How this effects the current code-base is that there would be no SaaS
login/registration pages. Another thing is, Stian correctly suggested
that the admin UI and admin REST services should be deployed and secured
by the token service as an Application under a realm. Both of these
things effect the design of the admin UI as well as provisioning,
installation, and bootstrapping
Knowing this there are two routes we can take.
Option #1: Multiple Realms per Keycloak Deployment (our current codebase)
Option #2: One Realm per Keycloak Deployment
Let's talk about Option #2 because I think it has the potential to make
things really clean. From both a UI perspective and
installation/bootstrapping perspective.
* The admin UI would be simplified as you would not have to have buttons
for creating realms or UI elements for switching between realms. Since
we want realm adminstration to be secured by the realm itself, adding
new realm admins is the same as managing any other user in the system.
If we allowed multiple realms per keycloak deployment, then we would
need the concept of a super user and separate UI elements for managing them.
* Installation/packaging Keycloak becomes simpler in the non-cloud case.
Keycloak would come pre-configured with a realm and a default admin
user for that realm with a known password. You would just boot up
Keycloak and try to login in. The admin user would force the user to
enter in a new password before they started using Keycloak.
* Provisioning on Openshift would also be simpler too, since the realm
name could map to a DNS name. myrealm-user.rhcloud.com
One realm per deployment doesn't mean that we would model it in the
database that way. The data model would still support multi-tenancy
which means you could share a database between Keycloak deployments.
Thoughts?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
Sync configuration of realm to configuration file
by Stian Thorgersen
Would it be a nice feature to be able to sync configuration of a realm to a configuration file?
The idea would be that OOTB Keycloak comes bundled with two files "keycloak-config-saas.json" and "keycloak-config-default.json". These would contain the initial config for the Realm used by Keycloak itself (users that can create realms, apps, etc..) and a default Realm that can be used by applications. There could be an option on a realm to enable syncing configuration changes to a file. If this is enabled any configuration changes would be written to "keycloak-config-<realm name>.json", and at startup the config in the db would be updated based on the config file. We could also add a watch the config files for updates, and sync into db at runtime as well.
13 years
Moving admin console into a separate project
by Stian Thorgersen
I've already mentioned this as part of the discussion around M1, but I thought it would make sense to create a separate thread for it here.
I propose that we move the SaaS admin console into a separate project in github (http://github.com/keycloak/keycloak-admin?). This would allow releasing the console separately from the core Keycloak server. Also, it allows not deploying the SaaS admin console if it's not required (for example for MBaaS, or for a simple internal server where config files/cli is used instead).
Also, I believe that the admin console should use TokenService for authentication, and that we drop all authentication, registration, etc. from SaasService.
13 years
User actions
by Stian Thorgersen
Unless someone else has already started to work on (or is very interested) I plan to work on account workflows. This work includes:
* Email verification
* Reset password
* Configure TOTP after registration if required by realm
* Marking user as requiring actions before they can login to applications
I've outlined a proposal on:
https://github.com/keycloak/keycloak/wiki/User-Actions
Finally, when an account is in the state of requiring actions (read the above wiki page to understand what I'm talking about!) the user should have access to the account management pages, but not to applications themselves. I was thinking in this case the accessCodeId could be passed as a query parameter, which would allow the account management pages to verify that the user is logged in, but at the same not enable SSO to applications (as the cookie isn't set yet). An alternative I was thinking of was that the SkeletonKeyToken could have the status added to it, but I don't like that approach as that would require applications to check the status. Any other suggestions?
13 years
M1 release scope
by Bill Burke
We need to decide what we want to do for M1. Here's my stab at it.
Let's discuss in email first as much as we can and then have a hangout
sometime next week to go over it and nail things down.
First and foremost. We have to focus. No new features. No playing
around. For example: no adding refresh token support. No client-cert
support. No changes to protocols. No new backends. Let's just use
Picketlink JDBC. No 'forgot password' using SMS, etc... You get the
picture.
Required:
* Social Broker login with as many providers as possible. Minimally
Google and Facebook.
* SSO and SLO (Single Log Out)
* Password and TOTP login
* OAuth Client Grant support
* Example with apps using all o these features
* Keycloak website setup and finalized
* Online video walking through a demonstration of features
* Online video walking though how to configure it
* JBoss 7.1.x Community and JBoss EAP 6.1 support
Knowing this there are two paths we can take. We can either include an
Admin UI in M1 or not. IMO, if we do *NOT* have an Admin UI for M1, we
probably need to not have registration or account management. Here's
what it might look like:
Option #1: No Input UIs
* A read-only XML/JSON file-based backend. Users must edit this to add
users, roles, etc...
* No Admin UI
* No Registration, forgotten passwords, account management. All these
require runtime updates to the database.
* What would we do about social though? As it requires registration?
Work required (time estimates could take shorter or longer depending on
interruptions):
* 1-2 man-weeks to do file-based back-end
* 1-5 days to design the OAuth Grant Pages.
* 1 day to incorporate Grant pages
* Do we want fancier demo apps to show SSO and OAuth Grants? If so,
this is minimum 2 weeks. 1 to get Event Juggler hooked into Keycloak.
1+ weeks to create another related SSO application. 1+ more to create
an OAuth application.
* 1 week to organize the Website and create demo videos.
* 1-2 weeks for documentation
* 1+ weeks to decide and implement how we're going to distribute
keycloak. Will it be a AS7 and/or EAP distro? A WAR? etc...
So best case scenario is end of October. It would minimally require
myself and Gabriel. Others would be needed if we want fancier demo apps
as it is beyond my ability to create a nice looking demo app in a short
period of time.
Option #2: UIs
This would take a lot more work as we would need to finish up the admin,
registration, and account management UIs. I'd say Christmas time would
be a viable M1 release for this. This would require everybody.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
Hangout to discuss M1
by Stian Thorgersen
It would be good to have a Hangout to discuss M1. What about 3pm UTC (same time as today's Hangout) on Thursday or Friday?
13 years
lost World of Warcraft authenticator
by Bill Burke
I recently had my iphone short and break because I got it wet. World of
Warcraft uses TOTP and I wanted to walk through the 3 different options
they have for handling lost authenticators.
Option 1: Remove the authenticator via the Web
This required specifying:
* Your secret answer. An "answer" being, what is the name of your pet
or something
* Email
* Attaching a image scan of your ID
Option 2: Remove the authenticator via an SMS message
Sends a verification SMS message to your phone that allows you to remove
the authenticator. Note it doesn't reset your password.
Option 3: Call up support
They asked for:
* 2 secret answers
* Address
* Phone number on account
They then allowed me to set up the authenticator on the phone in which I
had to give them the autogenerated key provided by the authenticator.
For Google Authenticator, it would have to be switched, the admin would
have to provide the totp key to the user to type in. The admin then had
you log in to make sure everything worked.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
