[keycloak-dev] Persistent grants - step 1

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>