11:30 a.m.
Here's my thoughts on device mgmt, both UI and protocol:
Scenario:
An iOS device as a "Brokerage App" installed. The app needs to do REST
invocations to be able to trade stocks, etc. Devices must be registered
in order to obtain permission. Flow would look like this:
* User installs app on iPad.
* User hits login button on app.
* User is redirected to browser with a Keycloak server URL
* User enters in credentials
* User is redirected to "Device Registration" page. Keycloak asks user
if it authorizes access to the device.
* Keycloak registers the device under the user and generates a device token
* User is redirected back to iPad ap
* iPad app gets auth code from redirect URL
* iPad makes REST request to obtain auth token *AND* a device token.
* iPad app stores the device token.
Next login is the same, except there is no "grant" page displayed. The
iPad app uses the "device token" as a credential to turn an access code
into an access token. These are all extensions we'll need to make to
the current OAuth protocol.
UI work:
The User Account Service will need a way to list registered devices so
the user can see it and manage it (i.e. remove a registered device).
Admin Console should have a way to define a "Device Type". The name,
description and scope of the device type is defined. "name" is used in
the initial OAuth grant as a client_id identifier so that Keycloak knows
what to display as a description in the
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:54 p.m.
+1 on this scenario
There is a different scenario:
* the mobile app does not require an actual user (e.g. think about
something like a News-App (e.g. "ESPN Sports Ticker")), but the device
still needs to be registered w/ a server, so that the server later can use
the device metadata for sending push notifications to the iOS / Android
device. The AeroGear UnifiedPush Server is doing it (currently) via HTTP
Basic (see [1]).
Is this some scenario you are interested in supporting as well? Or is the
(current) focus more around storing 'devices' / 'device metadata' under a
real user (which is most-likely a pure enterprise use-case)?
Greetings,
Matthias
[1] http://aerogear.org/docs/specs/aerogear-push-rest/DeviceRegistration/
On Fri, Jan 24, 2014 at 5:30 PM, Bill Burke <bburke(a)redhat.com> wrote:
Here's my thoughts on device mgmt, both UI and protocol:
Scenario:
An iOS device as a "Brokerage App" installed. The app needs to do REST
invocations to be able to trade stocks, etc. Devices must be registered
in order to obtain permission. Flow would look like this:
* User installs app on iPad.
* User hits login button on app.
* User is redirected to browser with a Keycloak server URL
* User enters in credentials
* User is redirected to "Device Registration" page. Keycloak asks user
if it authorizes access to the device.
* Keycloak registers the device under the user and generates a device token
* User is redirected back to iPad ap
* iPad app gets auth code from redirect URL
* iPad makes REST request to obtain auth token *AND* a device token.
* iPad app stores the device token.
Next login is the same, except there is no "grant" page displayed. The
iPad app uses the "device token" as a credential to turn an access code
into an access token. These are all extensions we'll need to make to
the current OAuth protocol.
UI work:
The User Account Service will need a way to list registered devices so
the user can see it and manage it (i.e. remove a registered device).
Admin Console should have a way to define a "Device Type". The name,
description and scope of the device type is defined. "name" is used in
the initial OAuth grant as a client_id identifier so that Keycloak knows
what to display as a description in the
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
1:19 p.m.
On 1/24/2014 12:54 PM, Matthias Wessendorf wrote:
+1 on this scenario
There is a different scenario:
* the mobile app does not require an actual user (e.g. think about
something like a News-App (e.g. "ESPN Sports Ticker")), but the device
still needs to be registered w/ a server, so that the server later can
use the device metadata for sending push notifications to the iOS /
Android device. The AeroGear UnifiedPush Server is doing it (currently)
via HTTP Basic (see [1]).
In this case, couldn't the device just use the registration API?
Is this some scenario you are interested in supporting as well? Or is
the (current) focus more around storing 'devices' / 'device metadata'
under a real user (which is most-likely a pure enterprise use-case)?
IMO, its not a pure enterprise use case. I access my brokerage acct via
my ipad and browser via the same credentials.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:41 p.m.
On Fri, Jan 24, 2014 at 7:19 PM, Bill Burke <bburke(a)redhat.com> wrote:
On 1/24/2014 12:54 PM, Matthias Wessendorf wrote:
> +1 on this scenario
>
>
> There is a different scenario:
>
> * the mobile app does not require an actual user (e.g. think about
> something like a News-App (e.g. "ESPN Sports Ticker")), but the device
> still needs to be registered w/ a server, so that the server later can
> use the device metadata for sending push notifications to the iOS /
> Android device. The AeroGear UnifiedPush Server is doing it (currently)
> via HTTP Basic (see [1]).
>
>
In this case, couldn't the device just use the registration API?
Of the UnifiedPush Server? Sure!
I was just wondering if you guys are interested in this scenario as well.
> Is this some scenario you are interested in supporting as well? Or is
> the (current) focus more around storing 'devices' / 'device
metadata'
> under a real user (which is most-likely a pure enterprise use-case)?
>
>
IMO, its not a pure enterprise use case. I access my brokerage acct via
my ipad and browser via the same credentials.
yep, I was more saying that requiring a user in order to use a mobile app
is a bit more enterprise-like (sure: Twitter/FB are NOT enterprise), than
have no user required at all(like the mentioned sports-news-ticker).
So the brokerage could be even done on your iPad, your Android phone, your
browser, etc ;-)
-Matthias
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:46 p.m.
On 1/24/2014 1:41 PM, Matthias Wessendorf wrote:
On Fri, Jan 24, 2014 at 7:19 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 1/24/2014 12:54 PM, Matthias Wessendorf wrote:
+1 on this scenario
There is a different scenario:
* the mobile app does not require an actual user (e.g. think about
something like a News-App (e.g. "ESPN Sports Ticker")), but the
device
still needs to be registered w/ a server, so that the server
later can
use the device metadata for sending push notifications to the iOS /
Android device. The AeroGear UnifiedPush Server is doing it
(currently)
via HTTP Basic (see [1]).
In this case, couldn't the device just use the registration API?
Of the UnifiedPush Server? Sure!
I was just wondering if you guys are interested in this scenario as well.
Actually, I don't know. Does a "ESPN Sports Ticker" even come under the
IDP umbrella? What exactly is being managed here?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:52 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Friday, 24 January, 2014 4:30:52 PM
Subject: [keycloak-dev] Device mgmt
Here's my thoughts on device mgmt, both UI and protocol:
Scenario:
An iOS device as a "Brokerage App" installed. The app needs to do REST
invocations to be able to trade stocks, etc. Devices must be registered
in order to obtain permission. Flow would look like this:
* User installs app on iPad.
* User hits login button on app.
* User is redirected to browser with a Keycloak server URL
Matt raised some issues around using a browser for OAuth2 and that Android may prevent it
in the future. I wonder if we could somehow provide a more integrated experience than
needing to use a browser. I don't really know much about app development on neither
iOS or Android so don't know how feasible that is.
* User enters in credentials
* User is redirected to "Device Registration" page. Keycloak asks user
if it authorizes access to the device.
Would it make sense to have this as an optional step? We could for example allow a device
to automatically register when user logs in with his credentials, but the user would still
be able to manage the device through account management later.
We could probably also the same mechanism for html5 applications. This would work the same
way and the "device" (browser) would get a device token which is stored in
localStorage (or cookie for older browsers if we're bothered about supporting them).
This can also be used to provide https://issues.jboss.org/browse/KEYCLOAK-242 (Add
remember machine option for two factor authentication).
* Keycloak registers the device under the user and generates a device
token
* User is redirected back to iPad ap
* iPad app gets auth code from redirect URL
* iPad makes REST request to obtain auth token *AND* a device token.
* iPad app stores the device token.
Next login is the same, except there is no "grant" page displayed. The
iPad app uses the "device token" as a credential to turn an access code
into an access token. These are all extensions we'll need to make to
the current OAuth protocol.
UI work:
The User Account Service will need a way to list registered devices so
the user can see it and manage it (i.e. remove a registered device).
Admin Console should have a way to define a "Device Type". The name,
description and scope of the device type is defined. "name" is used in
the initial OAuth grant as a client_id identifier so that Keycloak knows
what to display as a description in the
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3737
days inactive
3743
days old
5 comments
3 participants
participants (3)
-
Bill Burke -
Matthias Wessendorf -
Stian Thorgersen