<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 September 2015 at 09:08, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 21/09/15 15:15, pslegr wrote:<br>
><br>
><br>
> On 21.9.2015 14:27, Marek Posolda wrote:<br>
>> On 21/09/15 12:28, pslegr wrote:<br>
>>><br>
>>><br>
>>> On 21.9.2015 12:06, Marek Posolda wrote:<br>
>>>> I've sent the PR . Right now it works like this:<br>
>>>><br>
>>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to<br>
>>>> retrieve offline tokens just if flag is enabled<br>
>>>><br>
>>>> - Offline token is classic refresh token with 2 differences. It has<br>
>>>> type<br>
>>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for<br>
>>>> offline<br>
>>>> token, the expiration value is 0, so it never expires.<br>
>>> Just an idea.<br>
>>> Have you ever thought, in terms of expiration, not only<br>
>>> about refresh vs. never expires<br>
>>> BUT also about defining the exact time of expiration ?<br>
>>> for example validity for 1 Month, 1 year, 3 years ... etc.<br>
>>> This would offer the possibility on the fly generate the so called;<br>
>>> "offline license tokens", which are<br>
>>> then used for different lifetime periods.<br>
>>> IMHO this might extend the usage for Keycloak into the license<br>
>>> providers field ;)<br>
>> We have already some support for required action "Terms & Condition"<br>
>> at the keycloak server level. AFAIK user needs to confirm "Terms &<br>
>> Conditions" page when he has that required action set on him. You<br>
>> have also possibility to customize the content of the page.<br>
>><br>
>> I wonder if this required action can be used for time based licences<br>
>> as well? Like for example you will have possibility to configure that<br>
>> validity of licence is 1 year, so after 1 year will be required<br>
>> action added to user automatically and he will need to confirm it<br>
>> again during login?<br>
> Well, I had more the offline licensing on my mind. In such situation<br>
> you would not ever communicate with the server from client.<br>
>><br>
>> The possibility you mentioned is about handling licence agreement at<br>
>> the client level by the application itself if I understand correctly?<br>
>> So application will save offline token and the token is valid for 3<br>
>> years, so application will display the licence screen when it<br>
>> notifies that offline token is expired. Am I understand correctly?<br>
> Yes, I think you pretty much got it<br>
> The thing is, once you imagine the offline license generation, then<br>
> this is a once time action, at the beginning. The license provider who<br>
> owns private keys makes that once and provide to the clients.<br>
> The token is then verified for offline actions and once expired must<br>
> be replaced by license provide again.<br>
</div></div>Interesting usecase. Looks there are more possibilities how to support this.<br>
<br>
1) We can add timeout for offline tokens (will be NEVER by default, so<br>
it will never expire).<br>
2) We can add the protocol mappers extension points for refresh tokens<br>
as well (currently we use protocol mappers just for generation of access<br>
tokens and ID tokens). This will allow even more flexibility in<br>
generating refresh/offline tokens and use different timeouts for<br>
different clients etc.<br>
3) Don't do anything directly in Keycloak, but let application handle<br>
this. When you receive offline token from Keycloak, you will save the<br>
offline token to your DB together with the time when offline token was<br>
received (you will handle the time by yourself, not from expiration<br>
field of offline token). Then your DB contains the time, so you can<br>
handle it in your application that after 3 years is token not valid<br>
anymore and the licence needs to be confirmed again.<br></blockquote><div><br></div><div>Not sure I fully understand what the use-case is around this, but it seems like what's being proposed is a complete misuse of offline tokens.</div><div><br></div><div>I'm assuming by licensing you mean something along the lines of a software license where a user has paid for a 1 year license for a particular application? If so offline tokens are not the solution as something like that should work with regular tokens as well. There's also a lot of other things to consider with regards to a license. You need a mechanism to add the license in the first place (a signed token perhaps associated with the users account), a way to renew the license (pay mechanism), etc.. It's not something we've had any demand for, nor do I really think it's something an authentication server should do.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>><br>
>> IMO extend the current Terms & Conditions action for expiration after<br>
>> some time looks better to me, as you won't need to do any more coding<br>
>> in your application. Just set the timeout for Terms&Conditions (or<br>
>> licence ) action at keycloak admin console.<br>
><br>
> Is the "Terms & Conditions action" something which works offline ?<br>
</span>No. It's displayed by Keycloak server, so it requires Keycloak server to<br>
be up and running.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marek<br>
</font></span><div class="HOEnZb"><div class="h5">><br>
> Pavel<br>
>><br>
>> Marek<br>
>>>><br>
>>>> - Offline token is generated by auth-server when client sends<br>
>>>> "scope=offline_access" . It's supported for classic browser flow, but<br>
>>>> also for Direct Grant flow or Service account flow.<br>
>>>><br>
>>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel<br>
>>>> with<br>
>>>> CRUD methods on UserModel. So when new offline token is generated by<br>
>>>> Keycloak, some info about current UserSession and ClientSession is<br>
>>>> persisted on UserModel. This means that offline token can be used to<br>
>>>> create new access token even if "normal" UserSession and ClientSession<br>
>>>> are already invalid or logged out.<br>
>>>><br>
>>>> - When refreshing access token with offline token, the auth-server<br>
>>>> won't<br>
>>>> send back another refresh token. It will send just accessToken +<br>
>>>> IDToken. This is to avoid writes to user database for each token<br>
>>>> refresh.<br>
>>>><br>
>>>> - In account management applications tab, there is new table column<br>
>>>> "Additional grants" where is shown if client has offline token for<br>
>>>> user.<br>
>>>> The click on "Revoke" button will remove offline tokens and granted<br>
>>>> consents as well - no separate actions for revoke consents and offline<br>
>>>> tokens.<br>
>>>><br>
>>>><br>
>>>> Still TODO:<br>
>>>> - Properly handle consents (see "Questions" below)<br>
>>>><br>
>>>> - More tests, example, export/import , docs<br>
>>>><br>
>>>> - More things/refactoring based on your feedback<br>
>>>><br>
>>>><br>
>>>> Questions:<br>
>>>> - The specs mentions that consent should be displayed when offline<br>
>>>> token<br>
>>>> is requested. See<br>
>>>> <a href="http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess" rel="noreferrer" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess</a> .<br>
>>>> Right now, I am not doing that. So when Client has "isConsentRequired"<br>
>>>> as false, the consent screen is not displayed. Now we also don't have<br>
>>>> support for "prompt=consent" (not sure if we need this) . Is it ok to<br>
>>>> keep it like this?<br>
>>>><br>
>>>> - I am thinking about adding new builtin client role "offline_access",<br>
>>>> which will be created for client when admin enables "offline tokens"<br>
>>>> switch. It will be used also as default role. This will allow that<br>
>>>> just<br>
>>>> some users are allowed to obtain offline-token (those which have this<br>
>>>> role). The role will be also displayed on consent screen for the<br>
>>>> clients, which needs consent.<br>
>>>> But that raises another question. IMO it will be good if role is<br>
>>>> requested and displayed on consent screen just if offline token is<br>
>>>> requested, but not when classic refresh token is requested.<br>
>>>><br>
>>>> Hence I was thinking about adding the flag "scopeParamMode" to<br>
>>>> RoleModel. The value true means that role will be requested and<br>
>>>> used in<br>
>>>> accessToken/refreshToken just if scope parameter contains it's value.<br>
>>>> This will be the setup for "offline_access" role, so it's used just<br>
>>>> for<br>
>>>> the offline token requests. Another thing is format of scope parameter<br>
>>>> with respect to realm roles and application roles. We can use "//" as<br>
>>>> delimiter, so realm role will have just "my-role" but client role will<br>
>>>> have "my-client//my-role" . The disadvantage is that for requesting<br>
>>>> offline_access you will then need to use scope like:<br>
>>>> "scope=customer-portal//offline_access" as it's client role.<br>
>>>><br>
>>>> WDYT? Any better idea?<br>
>>>><br>
>>>> Marek<br>
>>>> _______________________________________________<br>
>>>> keycloak-dev mailing list<br>
>>>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>>><br>
>><br>
><br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div></div>