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