Persistent grants - step 1
by Marek Posolda
I've sent startup PR for persistent grants. I've added
GrantedConsentModel (is it good name?) to track the roles and protocol
mappers user granted on consent screen. Consent screen is not displayed
if user already approved roles and protocol mappers before. There is
also new "Access" tab in account management where can user see
previously granted consents and revoke them for particular client. Is
"Access" good name for the tab?
There is still some work and I will continue if you don't have any
comments to the current impl. Remaining TODO is:
- representations
- Mongo model (for now I have just JPA. I hope that "file" model could
be skipped for now?)
- More automated tests
Some additional things to discuss:
- I would like to add
ClientSessionModel.setProtocolMappers/getProtocolMappers (Set<String>
with Ids of protocolMappers similarly like current getRoles/setRoles).
There is one small issue that protocolMappers are actually always
computed from the ClientModel, which means that there could be
theoreticallly different protocolMappers displayed to user and then
later saved to persistent model. Also later we want to add support for
"scope" parameter, which means that protocolMappers on the consent
screen could be really different than protocolMappers from the
ClientModel. Any objections against it?
- It may be good to add ClientModel.setDescription/getDescription, so on
the consent screen and in Account management Access page is displayed
the more proper (and localized) description of the client instead of
clientId (ie. "Have User Privileges in ThirdParty Application" instead
of "Have User Privileges in third-party"). Any objections against it?
- There is bit related issue
https://issues.jboss.org/browse/KEYCLOAK-1216 that click on "Logout all
sessions" in Account management doesn't propagate logout to the apps.
Currently I invalidate clientSessions of particular client and user
during revoke, but also don't propagate it to the applications. I would
like to change that and propagate it and also fix KEYCLOAK-1216 at the
same time. There will be still small issue for JS applications, because
when just clientSession of JS application is revoked, the logout won't
be propagated to the actual application because KEYCLOAK_SESSION cookie
is still valid. So for JS applications, the application will be really
logged later when accessToken expires. Any objections against it? Any
idea how to propagate revoke to JS applications?
Thanks,
Marek
11 years
out of memory errors on build
by Bill Burke
Keycloak master build is really slow and ends up failing with out of
memory errors. My maven opts are set to 1 gigabyte max ram. Somebody
introduced something nasty in the last few days.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Handle case when KC fails to send logout message to some application - KEYCLOAK 782
by Michał Choiński
Hi everyone!
I'm a potential GSOC student dreaming of working on "Keycloak -
Certificate Management" project. I spent last few days analysing the
code, debuging and looking how it really works on the inside.
I'd like to fix a bug which I've chosen from Jira. The issue number is
KEYCLOAK-782.
In OAuth 2.0 specification (RFC6749) I found the following parameters
(within item 4.1.2.1. Error Response) :
server_error
The authorization server encountered an unexpected
condition that prevented it from fulfilling the request.
(This error code is needed because a 500 Internal Server
Error HTTP status code cannot be returned to the client
via an HTTP redirect.)
error_description
OPTIONAL. Human-readable ASCII [USASCII] text providing
additional information, used to assist the client developer in
understanding the error that occurred.
Values for the "error_description" parameter MUST NOT include
characters outside the set %x20-21 / %x23-5B / %x5D-7E.
So the uri after logout would look like this:
...&error=server_error&error_description=Logout+from+some+apps+failed
The error_description could be either human readable description or just
an error code. It should be processed on client side. Keycloak.js should
be changed to handle it.
These params should be added to OIDCLoginProtocol and of course to
response when such an error occur.
In first loop iterating on userSessions placed in
AuthenticationManager.browserLogout there should be saving error when
backend logout fails. It could be done by adding a note to userSession
and getting it in finishLogout (first, of course, checking if it exists).
What do you think about the above mentioned solution?
best regards,
Michal Choinski
11 years
Added KeycloakContext (and updates to JBossLoggingEventListenerProvider)
by Stian Thorgersen
I've added KeycloakContext to KeycloakSession. This should help us to not have to pass around things like UriInfo, RealmModel, etc..
I've not refactored much of existing code, we can do that as we go along. In the future get things from KeycloakContext instead of passing it or injecting it. One thing I did was to get rid of the "Flows" stuff which was pretty much gone any ways.
This also provides access to these values for all providers (for example access to cookies within events requested by jboss.org guys, KEYCLOAK-1042).
To test this out I've updated JBossLoggingEventListenerProvider. JBossLoggingEventListenerProvider is now added by default to new realms making it easier to enable log for events. By default success events are logged with debug and error events are logged with warn, this can be changed in keycloak-server.json. To view events enable debug for "org.keycloak.events". If you set "org.keycloak.events" to trace it will also add requestUri and cookies to the log output.
Check out https://github.com/keycloak/keycloak/blob/master/events/jboss-logging/src... for some code ;)
11 years
