undertow adapter committed
by Bill Burke
Its only partially done, but works for SSO/bearer tokens. Should work
for CORS but haven't tested yet. Also still need to implemente sign-off
too. I'll finish it up once Undertow beta23 is released and integrated
with Wildfly master.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 1 month
first release dec 3rd
by Bill Burke
I'd like to do release Dec 3rd. Let's have a hangout early next week
(tues or wed) to discuss what needs to be done. Let's start a few
emails too before hand to gather what still needs to minimally be done
and what needs to be pushed to a later release.
FYI, we can't support Wildfly yet either as a distribution or as an
adapter as there is a session cookie bug in Undertow. The security SPI
is also changing slightly between Wildfly Beta 1 and Beta 2 which would
break our adapter anyways. I'm going to finish up what I have and start
helping close out the JIRAs we need, then put together a presentation
and documentation as well as clean up the website.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 1 month
need oauth client pages
by Bill Burke
I have the back end set up for this, but not the UI screens.
Basically its the same screens as Application minus "roles",
"installation", and "sessions".
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 1 month
Removing wildcard role
by Stian Thorgersen
Removing the wildcard role has two side-effects:
1. Tokens for an application no longer contains roles for the application itself - unless you explicitly add scope mappings to the application for its own roles
2. Application useRealmMappings doesn't result in realm roles being added to token
I've solved 1 by making TokenManager.createAccessCode add the applications own roles to requested roles. Also, as I've removed the application itself from the list of applications on an applications scope mappings page. An alternative approach would be to add scope mappings for an applications own roles when they are added, but I thought that was less elegant.
I didn't think 2 made sense any more without wildcard roles, so I've removed it, is that ok?
If you'd like to take a look at what I've done look at: https://github.com/stianst/keycloak/tree/remove-wildcard-role
11 years, 1 month
Don't show KEYCLOAK_APPLICATION and KEYCLOAK_IDENTITY_REQUESTER externally
by Stian Thorgersen
Should KEYCLOAK_APPLICATION or KEYCLOAK_IDENTITY_REQUESTER be visible at all externally (both in REST endpoints and admin console)?
I was thinking that these roles should be removed from the list of roles returned, and if anyone tries to delete a role starting with "KEYCLOAK_" a not found should be returned.
11 years, 1 month
Admin console
by Stian Thorgersen
Alexandre and Villiam are both nearly finished with the tasks they had on the admin console. Do you have anything else they can work on?
11 years, 1 month
Maven repository
by Stian Thorgersen
It would be great if we could get Maven repository for Keycloak soon so that we could release a timestamped version.
11 years, 1 month
Account roles
by Stian Thorgersen
The account management application provides access for users to manage their accounts, it also lets you retrieve the full user profile.
At the moment there are two roles associated with the account application:
* view-profile - retrive the user profile (produces json)
* manage-account - management the account (produces html, and consumes forms)
A lot of sites splits the profile and email, but I don't really see the point in this. If you can retrieve a persons full name, postal address, dob, etc is it really that problematic that you get access to the email as well?
At the moment account management is really restricted to a user doing this directly through the account application. In the future we should add support for json to all these methods. Once we do that we'd probably also want to add more fine-grained roles, for example allow an oauth client to update the user profile, but not change the password.
Another thing I wasn't quite sure about was if these roles should have been realm roles, instead of roles for the account application.
11 years, 1 month
default roles vs. registration roles
by Bill Burke
I think you're going about the default roles thing wrong as far as UI
goes. Since default roles really are only useful for newly registered
users they should be configured in one place under a "registration" menu
item in the "Realm" section of the Admin UI. The way it is now, you'd
have to go to possibly N different screens to configure roles applied to
a newly registered user.
So this "registration" config page would look pretty much like the role
mapping page in which you select roles you want applied when
registering. When we have composite roles this page should
automatically manage a "REGISTRATION" composite role behind the scenes.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 1 month
