<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 22.9.2015 09:16, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAdQXU96-VKEGLi50uM8GX=h1PE_FoTsZSzcWf7uteGB_Q@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</div>
</blockquote>
Yes you are correct, this is a SW license related thing.<br>
I must admit that AAA servers normally don't have such things and
the questions is if they really should. <br>
I can't remember seeing out there something offering complex
solutions for online & offline licensing. (I mean unpaid, being
opensource)<br>
Once providing an offline "permanent" tokens, this smells more the
SW license way and that was the reasoning behind my questions ;)<br>
I don't say this is a use-case for Keycloak directly, but you do
have already lot's of code there, which can be reused or bent to
work for SW licenses as well :)<br>
cheers<br>
Pavel<br>
<br>
<blockquote
cite="mid:CAJgngAdQXU96-VKEGLi50uM8GX=h1PE_FoTsZSzcWf7uteGB_Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>