[keycloak-dev] Offline tokens - step 1

Tue Sep 22 09:03:42 EDT 2015

I would say in this case it's more about bending than reusing ;)

On 22 September 2015 at 14:59, pslegr <pslegr at redhat.com> wrote:

>
>
> On 22.9.2015 09:16, Stian Thorgersen wrote:
>
>
>
> On 22 September 2015 at 09:08, Marek Posolda <mposolda at redhat.com> wrote:
>
>> 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.
>> Interesting usecase. Looks there are more possibilities how to support
>> this.
>>
>> 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.
>
> Yes you are correct, this is a SW license related thing.
> 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 at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>
>> >>
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150922/ecdfb640/attachment-0001.html 