11:06 a.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Friday, April 17, 2015 2:32:30 PM
Subject: [keycloak-dev] Persistent grants - step 1
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?
UserConsentModel?
I'd rather call the page in account management 'Applications' tab. One thing
I'd like us to add is a list of applications a user can access. It makes more sense to
me to have a single place to view everything related to applications (which are available,
what access do they have, what sessions are they logged-in to, etc..) than having multiple
pages.
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?
+1 To add, but call it ClientModel.get/setName instead. This makes me think that we need a
way to manage localized labels through the console. If someone sets name of a client to
${myClient} then they should also be able to add translations to it through the admin
console. That's something to implement later though.
- 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?
Assuming 1216 is the way it's work all along, let's postpone that. Same goes for
propagating "consent revocation" to apps, jira it and postpone to next release.
Thanks,
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev