Unassigned by default
by Stian Thorgersen
I've now set all existing issues (except for a few) to unassigned. I may have set some issues that you where working on or planning to work to unassigned, if so just grab them straight away.
Basic rule should be before you plan to work on an issue assign it to yourself. If someone else has an issue you'd like to work on, but it's assigned to them, talk to them directly prior to working on it.
Also, for larger issues (+2 days sort of things) it could be an idea to fire an email first on how you plan to attack it.
11 years, 11 months
management problems
by Bill Burke
Our current "master realm" structure/design is deficient. Consider an
application like UPS that wants to use Keycloak to manage users. This
application would also have its own management console whose security is
also managed by keycloak.
My first thought is that you could define the application's management
console as an application in the "master" keycloak realm. This solution
isn't a great one if the keycloak server is managing multiple realms.
So, IMO not something we should recommend.
Another option is to define admin roles within the application's realm
itself. These roles are assignable to users within the realm. This
would require rethinking of the Angular JS admin console and how things
are authenticated and how people log-in. We should probably treat this
as SSO and have individual applications within the application realm,
for example:
UPS Realm registered applications:
realm-management (keycloak admin console)
aerogear-ups-management (ups admin console)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
dynamic key look and relative uri support added
by Bill Burke
* For adapter config, you can now leave out the realm's public key as
long as you have a valid auth-server-url. Keycloak will now ping this
auth server to obtain the public key for the realm.
* The adapter config supports a relative URI for the auth-server-url.
It will use the current requests scheme, host, and port to create urls.
A relative url examples is: "/auth"
* The auth server supports relative URLS for redirect urls, admin urls,
and base urls. i.e. "/customer-portal/*". The current request is used
to to build the redirect url to validate against, THe scheme, host, and
port is used.
With these changes, it makes it a bit easier to bundle preconfigured
apps and keycloak on a single server. Hoping this will resolve a bunch
of Aerogear issues.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
Account management requirements for beta1
by Stian Thorgersen
With regards to account management what additional requirements do we have for beta1?
Features I can think off to add now or in the future includes:
* Manage refresh tokens - view applications and clients that have refresh tokens, and the ability to invalidate specific tokens
* Manage devices - view browsers and devices that have access (remember me cookie?), and the ability to invalidate specific cookies
* Manage devices that can bypass totp - it seems to be quite common that it's possible to not require asking for totp again for a specific device, I assume this is done by setting a cookie, if we enable this it should be possible to view what devices have this option, as well as invalidate them
* Manage applications - view all applications, be able to navigate to an application, and the ability to invalidate access to specific application
* Manage clients - view all clients and what grants they have, and the ability to revoke access to specific client
I think listing client grants, invalidate specific client grants, and a logout everything option would be sufficient. The logout everything option would invalidate any refresh tokens, remember me cookies, 'skip' totp cookies and do a sso-logout.
11 years, 11 months
Plan for final release
by Stian Thorgersen
What are the general plans for the final release in June. I think we need to finish of the crucial features asap for beta1, then have a release cycle each for performance, testing and security. What about the following release schedule:
* 12 May Beta1 - Feature freeze
* 19 May Beta2 - Performance
* 26 May Beta3 - Testing
* 2 June RC1 - Security
* 16 June Final
With regards to Beta1 what are the outstanding required features? Those I can think of are:
* Brute force protection - what's the status on this?
* Import/export - Marek has started work on this
* Logout everything through acct mngmt - invalidate grants, refresh tokens, cookies, etc for user
* Dependencies for EAP - including support for Resteasy 2.3.6
* Two WARs bootstrapping example for AeroGear
* LDAP integration - Marek is pretty much done with this
Lower priority features:
* Email on events - email user/admin on various events, for example if brute force protection suspects someone is trying to hack the account
* Social login remember me
* Single-sign out for JS adapter
* Add realm option to enable/disable "Resource Owner Password Credentials Grant"
* Filter what events are audited
* Expose/Embed Version information
11 years, 11 months