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