11:16 p.m.
Hi All,
I apologize for the long email :)
The new account console should provide a nice feature (see attachment) to
help users to track their devices activity. I think the main goal is not to
be 100% accurate (mainly because device identification is not an easy task)
but let users know about:
* The devices the user is using to authenticate
* Suspicious behavior either from devices that are not known or based on
the last time a device was used to authenticate
I would like to share what I've done so far and what the next steps could
be. I've submitted a WIP [1] that basically relies on the User-Agent header
to obtain info about devices.
Device identification is based on the OS and Device (if available from user
agent), where requests from the same IP are considered as being from the
same device. If the IP is different, we check session id, if it is the
same, the request is from the same device. If you use a different browser
you also have that grouped and available as a list from the device
representation. It is worth mentioning that device management is only
performed when a session is created in Keycloak, or it is used when
processing a request. One thing to consider is that if running behind a
proxy, Keycloak should be able to obtain the original client address from a
header.
By using the device/client IP as an identifier, I'm also trying to avoid
creating a new device if the session is still active. If so, we assume that
the request comes from the same device and we just update that info, so
that subsequent requests will match by IP.
However, if the session ends and the IP changes, a new device will be
created (if the device session was not updated). To overcome that, I think
we could:
* Support a specific cookie to identify devices (UUID)
* Allow clients connecting to Keycloak to provide a device fingerprint
(sent as a header, for instance), with restrictions on which clients can do
that
* Geolocation
* Anything else?
The first two options are useful depending on the client.
For browsers, cookies are more natural. Yes, users can clear browser data.
but in the worst case, he will get a new device entry and we'll show that.
Still, a good option IMO.
Device fingerprint may be useful for mobile apps or other types of clients
that are capable of providing a unique and trustworthy identifier. It can
be used for browsers too, but I think this implies more privacy/security
concerns.
Regarding the third one above (geolocation), I'll skip for now as we can
live without it in a first version of the feature. Although it would enrich
even more the functionality as well as the discussions happening around MFA
and adaptive authentication.
Data purging is another concern. Right now we don't have anything at this
regards, but I would like to expire entries based on the last time they
were accessed. Or maybe this something we should just keep and admins
should be responsible for purging data as it may imply privacy and security
concerns that are specific to a particular use case.
For last, I think we should probably have a switch for this feature. So
admins can enable/disable it accordingly with their needs. Not sure if this
kind of stuff makes always sense.
[1] https://github.com/keycloak/keycloak/pull/6217
9:24 a.m.
Hi Pedro,
Nice feature but why considering request from same ip as from the same device?
If you are using a fixed connection with several devices using it, then it may be easily
the case that different devices have been used.
Cheers,
Federico
Dr. FEDERICO MICHELE FACCA
CTO
0041 78 807 58 38
Martel Innovate - Professional support for innovation projects
Click to download our innovators' insights!
Follow Us on Twitter
Il giorno 1 ago 2019, alle ore 23:16, Pedro Igor Silva
<psilva(a)redhat.com> ha scritto:
Hi All,
I apologize for the long email :)
The new account console should provide a nice feature (see attachment) to
help users to track their devices activity. I think the main goal is not to
be 100% accurate (mainly because device identification is not an easy task)
but let users know about:
* The devices the user is using to authenticate
* Suspicious behavior either from devices that are not known or based on
the last time a device was used to authenticate
I would like to share what I've done so far and what the next steps could
be. I've submitted a WIP [1] that basically relies on the User-Agent header
to obtain info about devices.
Device identification is based on the OS and Device (if available from user
agent), where requests from the same IP are considered as being from the
same device. If the IP is different, we check session id, if it is the
same, the request is from the same device. If you use a different browser
you also have that grouped and available as a list from the device
representation. It is worth mentioning that device management is only
performed when a session is created in Keycloak, or it is used when
processing a request. One thing to consider is that if running behind a
proxy, Keycloak should be able to obtain the original client address from a
header.
By using the device/client IP as an identifier, I'm also trying to avoid
creating a new device if the session is still active. If so, we assume that
the request comes from the same device and we just update that info, so
that subsequent requests will match by IP.
However, if the session ends and the IP changes, a new device will be
created (if the device session was not updated). To overcome that, I think
we could:
* Support a specific cookie to identify devices (UUID)
* Allow clients connecting to Keycloak to provide a device fingerprint
(sent as a header, for instance), with restrictions on which clients can do
that
* Geolocation
* Anything else?
The first two options are useful depending on the client.
For browsers, cookies are more natural. Yes, users can clear browser data.
but in the worst case, he will get a new device entry and we'll show that.
Still, a good option IMO.
Device fingerprint may be useful for mobile apps or other types of clients
that are capable of providing a unique and trustworthy identifier. It can
be used for browsers too, but I think this implies more privacy/security
concerns.
Regarding the third one above (geolocation), I'll skip for now as we can
live without it in a first version of the feature. Although it would enrich
even more the functionality as well as the discussions happening around MFA
and adaptive authentication.
Data purging is another concern. Right now we don't have anything at this
regards, but I would like to expire entries based on the last time they
were accessed. Or maybe this something we should just keep and admins
should be responsible for purging data as it may imply privacy and security
concerns that are specific to a particular use case.
For last, I think we should probably have a switch for this feature. So
admins can enable/disable it accordingly with their needs. Not sure if this
kind of stuff makes always sense.
[1] https://github.com/keycloak/keycloak/pull/6217
<DeviceActivity.png>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:59 p.m.
Hi Federico,
If these devices are authenticating through a browser and User-Agent is
set, you'll have different entries for each device, even though they have
the same IP. It is not only based on IP but the OS information gathered
from the User-Agent header.
However, if you are not doing code grant through a browser, we should
probably allow devices to push a fingerprint. Right now, the functionality
is based on User-Agent, so if your devices are able to set this header you
should have specific entries for each.
On Fri, Aug 2, 2019 at 4:24 AM Federico Michele Facca <
federico.facca(a)martel-innovate.com> wrote:
Hi Pedro,
Nice feature but why considering request from same ip as from the same
device?
If you are using a fixed connection with several devices using it, then it
may be easily the case that different devices have been used.
Cheers,
Federico
*Dr. FEDERICO MICHELE FACCA*
*CTO*
0041 78 807 58 38
*Martel Innovate* <https://www.martel-innovate.com/> - Professional
support for innovation projects
Click to download our innovators' insights!
<https://www.martel-innovate.com/premium-content/>
Follow Us on Twitter <https://twitter.com/Martel_Innovate>
Il giorno 1 ago 2019, alle ore 23:16, Pedro Igor Silva <psilva(a)redhat.com>
ha scritto:
Hi All,
I apologize for the long email :)
The new account console should provide a nice feature (see attachment) to
help users to track their devices activity. I think the main goal is not to
be 100% accurate (mainly because device identification is not an easy task)
but let users know about:
* The devices the user is using to authenticate
* Suspicious behavior either from devices that are not known or based on
the last time a device was used to authenticate
I would like to share what I've done so far and what the next steps could
be. I've submitted a WIP [1] that basically relies on the User-Agent header
to obtain info about devices.
Device identification is based on the OS and Device (if available from user
agent), where requests from the same IP are considered as being from the
same device. If the IP is different, we check session id, if it is the
same, the request is from the same device. If you use a different browser
you also have that grouped and available as a list from the device
representation. It is worth mentioning that device management is only
performed when a session is created in Keycloak, or it is used when
processing a request. One thing to consider is that if running behind a
proxy, Keycloak should be able to obtain the original client address from a
header.
By using the device/client IP as an identifier, I'm also trying to avoid
creating a new device if the session is still active. If so, we assume that
the request comes from the same device and we just update that info, so
that subsequent requests will match by IP.
However, if the session ends and the IP changes, a new device will be
created (if the device session was not updated). To overcome that, I think
we could:
* Support a specific cookie to identify devices (UUID)
* Allow clients connecting to Keycloak to provide a device fingerprint
(sent as a header, for instance), with restrictions on which clients can do
that
* Geolocation
* Anything else?
The first two options are useful depending on the client.
For browsers, cookies are more natural. Yes, users can clear browser data.
but in the worst case, he will get a new device entry and we'll show that.
Still, a good option IMO.
Device fingerprint may be useful for mobile apps or other types of clients
that are capable of providing a unique and trustworthy identifier. It can
be used for browsers too, but I think this implies more privacy/security
concerns.
Regarding the third one above (geolocation), I'll skip for now as we can
live without it in a first version of the feature. Although it would enrich
even more the functionality as well as the discussions happening around MFA
and adaptive authentication.
Data purging is another concern. Right now we don't have anything at this
regards, but I would like to expire entries based on the last time they
were accessed. Or maybe this something we should just keep and admins
should be responsible for purging data as it may imply privacy and security
concerns that are specific to a particular use case.
For last, I think we should probably have a switch for this feature. So
admins can enable/disable it accordingly with their needs. Not sure if this
kind of stuff makes always sense.
[1] https://github.com/keycloak/keycloak/pull/6217
<DeviceActivity.png>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:49 p.m.
My IP address can change several times in a session as I move between
mobile networks, public wifi and home/office internet connections,
enabling/disabling a VPN. I think perhaps IP address isn't a reliable
component of the identity of the device - I wouldn't find a list of every
network I have ever joined on my mobile under the 'my devices' section very
useful. However, there are device fingerprinting libraries out there that
can identity the particular device using a number of factors - would using
one of these help identify the device? E.g. https://fingerprintjs.com/. Also,
for WebAuthn, you could associate the registered authenticators with a
device, so any time those authenticators are used you have a high degree of
confidence that the associated device was the one being used.
For native apps using a direct grant, you have a little more control - a
keypair & challenge for a signature is sometimes used to prove which device
is being used, and for devices that register to get a client secret, a good
starting point may be to assume that the client identified by the client_id
is the device.
I wonder if an SPI or config option could be set for Clients or auth flows
to use different techniques for fingerprinting. E.g. for web flows, use
this JS library, for direct grant flows, use this other technique.
Jon
On Fri, 2 Aug 2019 at 12:16, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Hi Federico,
If these devices are authenticating through a browser and User-Agent is
set, you'll have different entries for each device, even though they have
the same IP. It is not only based on IP but the OS information gathered
from the User-Agent header.
However, if you are not doing code grant through a browser, we should
probably allow devices to push a fingerprint. Right now, the functionality
is based on User-Agent, so if your devices are able to set this header you
should have specific entries for each.
On Fri, Aug 2, 2019 at 4:24 AM Federico Michele Facca <
federico.facca(a)martel-innovate.com> wrote:
> Hi Pedro,
>
> Nice feature but why considering request from same ip as from the same
> device?
> If you are using a fixed connection with several devices using it, then
it
> may be easily the case that different devices have been used.
>
> Cheers,
> Federico
>
>
> *Dr. FEDERICO MICHELE FACCA*
> *CTO*
> 0041 78 807 58 38
> *Martel Innovate* <https://www.martel-innovate.com/> - Professional
> support for innovation projects
> Click to download our innovators' insights!
> <https://www.martel-innovate.com/premium-content/>
> Follow Us on Twitter <https://twitter.com/Martel_Innovate>
>
> Il giorno 1 ago 2019, alle ore 23:16, Pedro Igor Silva <
psilva(a)redhat.com>
> ha scritto:
>
> Hi All,
>
> I apologize for the long email :)
>
> The new account console should provide a nice feature (see attachment) to
> help users to track their devices activity. I think the main goal is not
to
> be 100% accurate (mainly because device identification is not an easy
task)
> but let users know about:
>
> * The devices the user is using to authenticate
> * Suspicious behavior either from devices that are not known or based on
> the last time a device was used to authenticate
>
> I would like to share what I've done so far and what the next steps could
> be. I've submitted a WIP [1] that basically relies on the User-Agent
header
> to obtain info about devices.
>
> Device identification is based on the OS and Device (if available from
user
> agent), where requests from the same IP are considered as being from the
> same device. If the IP is different, we check session id, if it is the
> same, the request is from the same device. If you use a different browser
> you also have that grouped and available as a list from the device
> representation. It is worth mentioning that device management is only
> performed when a session is created in Keycloak, or it is used when
> processing a request. One thing to consider is that if running behind a
> proxy, Keycloak should be able to obtain the original client address
from a
> header.
>
> By using the device/client IP as an identifier, I'm also trying to avoid
> creating a new device if the session is still active. If so, we assume
that
> the request comes from the same device and we just update that info, so
> that subsequent requests will match by IP.
>
> However, if the session ends and the IP changes, a new device will be
> created (if the device session was not updated). To overcome that, I
think
> we could:
>
> * Support a specific cookie to identify devices (UUID)
> * Allow clients connecting to Keycloak to provide a device fingerprint
> (sent as a header, for instance), with restrictions on which clients can
do
> that
> * Geolocation
> * Anything else?
>
> The first two options are useful depending on the client.
>
> For browsers, cookies are more natural. Yes, users can clear browser
data.
> but in the worst case, he will get a new device entry and we'll show
that.
> Still, a good option IMO.
>
> Device fingerprint may be useful for mobile apps or other types of
clients
> that are capable of providing a unique and trustworthy identifier. It can
> be used for browsers too, but I think this implies more privacy/security
> concerns.
>
> Regarding the third one above (geolocation), I'll skip for now as we can
> live without it in a first version of the feature. Although it would
enrich
> even more the functionality as well as the discussions happening around
MFA
> and adaptive authentication.
>
> Data purging is another concern. Right now we don't have anything at this
> regards, but I would like to expire entries based on the last time they
> were accessed. Or maybe this something we should just keep and admins
> should be responsible for purging data as it may imply privacy and
security
> concerns that are specific to a particular use case.
>
> For last, I think we should probably have a switch for this feature. So
> admins can enable/disable it accordingly with their needs. Not sure if
this
> kind of stuff makes always sense.
>
> [1] https://github.com/keycloak/keycloak/pull/6217
>
> <DeviceActivity.png>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
[image: Backbase] <https://backbase.com/>*Jon Meyler*
Software Architect · R&D · Cardiff
LinkedIn <https://www.linkedin.com/company/backbase> · Twitter
<https://www.twitter.com/backbase> · Careers <http://careers.backbase.com/>
3:49 p.m.
On Sat, Aug 3, 2019 at 7:49 AM Jonathan Meyler <jonathanm(a)backbase.com>
wrote:
My IP address can change several times in a session as I move
between
mobile networks, public wifi and home/office internet connections,
enabling/disabling a VPN. I think perhaps IP address isn't a reliable
component of the identity of the device - I wouldn't find a list of every
network I have ever joined on my mobile under the 'my devices' section very
useful.
You are right, it is not. However, to overcome the scenario you mentioned
when IP address changes within a session lifetime, the initial idea, and
implementation, also consider the session when deciding whether or not the
device is the same. So, if your device is querying the server using
different IP addresses during a period using the same session, you'll not
have additional entries in the user's device activity. As I said in my
original email and in one of my replies, we also update the IP address
every time you reach Keycloak. So, even if you have a different session but
the IP was updated before the previous session ended, the device will be
recognized as being the same. Otherwise, I new entry will be recorded (that
is one of the reasons for having both "device cookie" and fingerprint in my
original email).
However, there are device fingerprinting libraries out there that
can
identity the particular device using a number of factors - would using one
of these help identify the device? E.g. https://fingerprintjs.com/. Also,
for WebAuthn, you could associate the registered authenticators with a
device, so any time those authenticators are used you have a high degree of
confidence that the associated device was the one being used.
I agree that WebAuthn should help to identify devices better. There is
useful information during registration that we could use to pass to the
server when making requests.
For native apps using a direct grant, you have a little more control - a
keypair & challenge for a signature is sometimes used to prove which device
is being used, and for devices that register to get a client secret, a good
starting point may be to assume that the client identified by the client_id
is the device.
I wonder if an SPI or config option could be set for Clients or auth flows
to use different techniques for fingerprinting. E.g. for web flows, use
this JS library, for direct grant flows, use this other technique.
That is one of the feedbacks I was expecting to get. If we are going to
allow clients to push fingerprints for the devices where they are running
(which some times is a 1:1 mapping) I also think we need an SPI to cover
different use cases. This SPI would be a hook for any custom logic that you
need to match a device. A default implementation could be as simple as
supporting a specific header that clients can set to requests with a
trustworthy and unique fingerprint. As I mentioned before, we should also
restrict the clients that can send fingerprints to the server.
For browsers, I still think that a cookie is a good default implementation
that would not force you to calculate a fingerprint. It should be enough
for some people and easier to get things running. We would still allow SPAs
to send fingerprints if necessary, so, server-side the behavior will be
just using that information instead of any defaults (cookie, ip+session,
etc).
What about having a switch to enable/disable this functionality. Wdyt ?
Jon
On Fri, 2 Aug 2019 at 12:16, Pedro Igor Silva <psilva(a)redhat.com> wrote:
> Hi Federico,
>
> If these devices are authenticating through a browser and User-Agent is
> set, you'll have different entries for each device, even though they have
> the same IP. It is not only based on IP but the OS information gathered
> from the User-Agent header.
>
> However, if you are not doing code grant through a browser, we should
> probably allow devices to push a fingerprint. Right now, the functionality
> is based on User-Agent, so if your devices are able to set this header you
> should have specific entries for each.
>
>
> On Fri, Aug 2, 2019 at 4:24 AM Federico Michele Facca <
> federico.facca(a)martel-innovate.com> wrote:
>
> > Hi Pedro,
> >
> > Nice feature but why considering request from same ip as from the same
> > device?
> > If you are using a fixed connection with several devices using it, then
> it
> > may be easily the case that different devices have been used.
> >
> > Cheers,
> > Federico
> >
> >
> > *Dr. FEDERICO MICHELE FACCA*
> > *CTO*
> > 0041 78 807 58 38
> > *Martel Innovate* <https://www.martel-innovate.com/> - Professional
> > support for innovation projects
> > Click to download our innovators' insights!
> > <https://www.martel-innovate.com/premium-content/>
> > Follow Us on Twitter <https://twitter.com/Martel_Innovate>
> >
> > Il giorno 1 ago 2019, alle ore 23:16, Pedro Igor Silva <
> psilva(a)redhat.com>
> > ha scritto:
> >
> > Hi All,
> >
> > I apologize for the long email :)
> >
> > The new account console should provide a nice feature (see attachment)
> to
> > help users to track their devices activity. I think the main goal is
> not to
> > be 100% accurate (mainly because device identification is not an easy
> task)
> > but let users know about:
> >
> > * The devices the user is using to authenticate
> > * Suspicious behavior either from devices that are not known or based on
> > the last time a device was used to authenticate
> >
> > I would like to share what I've done so far and what the next steps
> could
> > be. I've submitted a WIP [1] that basically relies on the User-Agent
> header
> > to obtain info about devices.
> >
> > Device identification is based on the OS and Device (if available from
> user
> > agent), where requests from the same IP are considered as being from the
> > same device. If the IP is different, we check session id, if it is the
> > same, the request is from the same device. If you use a different
> browser
> > you also have that grouped and available as a list from the device
> > representation. It is worth mentioning that device management is only
> > performed when a session is created in Keycloak, or it is used when
> > processing a request. One thing to consider is that if running behind a
> > proxy, Keycloak should be able to obtain the original client address
> from a
> > header.
> >
> > By using the device/client IP as an identifier, I'm also trying to avoid
> > creating a new device if the session is still active. If so, we assume
> that
> > the request comes from the same device and we just update that info, so
> > that subsequent requests will match by IP.
> >
> > However, if the session ends and the IP changes, a new device will be
> > created (if the device session was not updated). To overcome that, I
> think
> > we could:
> >
> > * Support a specific cookie to identify devices (UUID)
> > * Allow clients connecting to Keycloak to provide a device fingerprint
> > (sent as a header, for instance), with restrictions on which clients
> can do
> > that
> > * Geolocation
> > * Anything else?
> >
> > The first two options are useful depending on the client.
> >
> > For browsers, cookies are more natural. Yes, users can clear browser
> data.
> > but in the worst case, he will get a new device entry and we'll show
> that.
> > Still, a good option IMO.
> >
> > Device fingerprint may be useful for mobile apps or other types of
> clients
> > that are capable of providing a unique and trustworthy identifier. It
> can
> > be used for browsers too, but I think this implies more privacy/security
> > concerns.
> >
> > Regarding the third one above (geolocation), I'll skip for now as we can
> > live without it in a first version of the feature. Although it would
> enrich
> > even more the functionality as well as the discussions happening around
> MFA
> > and adaptive authentication.
> >
> > Data purging is another concern. Right now we don't have anything at
> this
> > regards, but I would like to expire entries based on the last time they
> > were accessed. Or maybe this something we should just keep and admins
> > should be responsible for purging data as it may imply privacy and
> security
> > concerns that are specific to a particular use case.
> >
> > For last, I think we should probably have a switch for this feature. So
> > admins can enable/disable it accordingly with their needs. Not sure if
> this
> > kind of stuff makes always sense.
> >
> > [1] https://github.com/keycloak/keycloak/pull/6217
> >
> > <DeviceActivity.png>
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
[image: Backbase] <https://backbase.com/>*Jon Meyler*
Software Architect · R&D · Cardiff
LinkedIn <https://www.linkedin.com/company/backbase> · Twitter
<https://www.twitter.com/backbase> · Careers
<http://careers.backbase.com/>
3:31 p.m.
On 05. 08. 19 15:49, Pedro Igor Silva wrote:
On Sat, Aug 3, 2019 at 7:49 AM Jonathan Meyler
<jonathanm(a)backbase.com>
wrote:
> My IP address can change several times in a session as I move between
> mobile networks, public wifi and home/office internet connections,
> enabling/disabling a VPN. I think perhaps IP address isn't a reliable
> component of the identity of the device - I wouldn't find a list of every
> network I have ever joined on my mobile under the 'my devices' section very
> useful.
>
You are right, it is not. However, to overcome the scenario you mentioned
when IP address changes within a session lifetime, the initial idea, and
implementation, also consider the session when deciding whether or not the
device is the same. So, if your device is querying the server using
different IP addresses during a period using the same session, you'll not
have additional entries in the user's device activity. As I said in my
original email and in one of my replies, we also update the IP address
every time you reach Keycloak. So, even if you have a different session but
the IP was updated before the previous session ended, the device will be
recognized as being the same. Otherwise, I new entry will be recorded (that
is one of the reasons for having both "device cookie" and fingerprint in my
original email).
One side-note, when I move my laptop to some different location
(EG.
restaurant, which I never attend before) I usually receive some warnings
from google. So they likely consider it as different device when IP
address changed.
> However, there are device fingerprinting libraries out there that
can
> identity the particular device using a number of factors - would using one
> of these help identify the device? E.g. https://fingerprintjs.com/. Also,
> for WebAuthn, you could associate the registered authenticators with a
> device, so any time those authenticators are used you have a high degree of
> confidence that the associated device was the one being used.
>
I agree that WebAuthn should help to identify devices better. There is
useful information during registration that we could use to pass to the
server when making requests.
> For native apps using a direct grant, you have a little more control - a
> keypair & challenge for a signature is sometimes used to prove which device
> is being used, and for devices that register to get a client secret, a good
> starting point may be to assume that the client identified by the client_id
> is the device.
>
> I wonder if an SPI or config option could be set for Clients or auth flows
> to use different techniques for fingerprinting. E.g. for web flows, use
> this JS library, for direct grant flows, use this other technique.
>
That is one of the feedbacks I was expecting to get. If we are going to
allow clients to push fingerprints for the devices where they are running
(which some times is a 1:1 mapping) I also think we need an SPI to cover
different use cases. This SPI would be a hook for any custom logic that you
need to match a device. A default implementation could be as simple as
supporting a specific header that clients can set to requests with a
trustworthy and unique fingerprint. As I mentioned before, we should also
restrict the clients that can send fingerprints to the server.
For browsers, I still think that a cookie is a good default implementation
that would not force you to calculate a fingerprint. It should be enough
for some people and easier to get things running. We would still allow SPAs
to send fingerprints if necessary, so, server-side the behavior will be
just using that information instead of any defaults (cookie, ip+session,
etc).
What about having a switch to enable/disable this functionality. Wdyt ?
Not sure about the switch for device functionality. Maybe we can add it
later if there is a demand? Less switches is always good and removing
switches can be harder than adding them :)
IMO feedback from community will be interesting. I guess some people may
have issues that IP address won't work, because Keycloak is behind proxy
and admin don't have possibility to configure the proxy headers. Not
sure if such deployment, where administrator can't properly configure
proxy, exists and how much of them, but maybe some are...
Marek
> Jon
>
>
> On Fri, 2 Aug 2019 at 12:16, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
>> Hi Federico,
>>
>> If these devices are authenticating through a browser and User-Agent is
>> set, you'll have different entries for each device, even though they have
>> the same IP. It is not only based on IP but the OS information gathered
>> from the User-Agent header.
>>
>> However, if you are not doing code grant through a browser, we should
>> probably allow devices to push a fingerprint. Right now, the functionality
>> is based on User-Agent, so if your devices are able to set this header you
>> should have specific entries for each.
>>
>>
>> On Fri, Aug 2, 2019 at 4:24 AM Federico Michele Facca <
>> federico.facca(a)martel-innovate.com> wrote:
>>
>>> Hi Pedro,
>>>
>>> Nice feature but why considering request from same ip as from the same
>>> device?
>>> If you are using a fixed connection with several devices using it, then
>> it
>>> may be easily the case that different devices have been used.
>>>
>>> Cheers,
>>> Federico
>>>
>>>
>>> *Dr. FEDERICO MICHELE FACCA*
>>> *CTO*
>>> 0041 78 807 58 38
>>> *Martel Innovate* <https://www.martel-innovate.com/> - Professional
>>> support for innovation projects
>>> Click to download our innovators' insights!
>>> <https://www.martel-innovate.com/premium-content/>
>>> Follow Us on Twitter <https://twitter.com/Martel_Innovate>
>>>
>>> Il giorno 1 ago 2019, alle ore 23:16, Pedro Igor Silva <
>> psilva(a)redhat.com>
>>> ha scritto:
>>>
>>> Hi All,
>>>
>>> I apologize for the long email :)
>>>
>>> The new account console should provide a nice feature (see attachment)
>> to
>>> help users to track their devices activity. I think the main goal is
>> not to
>>> be 100% accurate (mainly because device identification is not an easy
>> task)
>>> but let users know about:
>>>
>>> * The devices the user is using to authenticate
>>> * Suspicious behavior either from devices that are not known or based on
>>> the last time a device was used to authenticate
>>>
>>> I would like to share what I've done so far and what the next steps
>> could
>>> be. I've submitted a WIP [1] that basically relies on the User-Agent
>> header
>>> to obtain info about devices.
>>>
>>> Device identification is based on the OS and Device (if available from
>> user
>>> agent), where requests from the same IP are considered as being from the
>>> same device. If the IP is different, we check session id, if it is the
>>> same, the request is from the same device. If you use a different
>> browser
>>> you also have that grouped and available as a list from the device
>>> representation. It is worth mentioning that device management is only
>>> performed when a session is created in Keycloak, or it is used when
>>> processing a request. One thing to consider is that if running behind a
>>> proxy, Keycloak should be able to obtain the original client address
>> from a
>>> header.
>>>
>>> By using the device/client IP as an identifier, I'm also trying to avoid
>>> creating a new device if the session is still active. If so, we assume
>> that
>>> the request comes from the same device and we just update that info, so
>>> that subsequent requests will match by IP.
>>>
>>> However, if the session ends and the IP changes, a new device will be
>>> created (if the device session was not updated). To overcome that, I
>> think
>>> we could:
>>>
>>> * Support a specific cookie to identify devices (UUID)
>>> * Allow clients connecting to Keycloak to provide a device fingerprint
>>> (sent as a header, for instance), with restrictions on which clients
>> can do
>>> that
>>> * Geolocation
>>> * Anything else?
>>>
>>> The first two options are useful depending on the client.
>>>
>>> For browsers, cookies are more natural. Yes, users can clear browser
>> data.
>>> but in the worst case, he will get a new device entry and we'll show
>> that.
>>> Still, a good option IMO.
>>>
>>> Device fingerprint may be useful for mobile apps or other types of
>> clients
>>> that are capable of providing a unique and trustworthy identifier. It
>> can
>>> be used for browsers too, but I think this implies more privacy/security
>>> concerns.
>>>
>>> Regarding the third one above (geolocation), I'll skip for now as we can
>>> live without it in a first version of the feature. Although it would
>> enrich
>>> even more the functionality as well as the discussions happening around
>> MFA
>>> and adaptive authentication.
>>>
>>> Data purging is another concern. Right now we don't have anything at
>> this
>>> regards, but I would like to expire entries based on the last time they
>>> were accessed. Or maybe this something we should just keep and admins
>>> should be responsible for purging data as it may imply privacy and
>> security
>>> concerns that are specific to a particular use case.
>>>
>>> For last, I think we should probably have a switch for this feature. So
>>> admins can enable/disable it accordingly with their needs. Not sure if
>> this
>>> kind of stuff makes always sense.
>>>
>>> [1] https://github.com/keycloak/keycloak/pull/6217
>>>
>>> <DeviceActivity.png>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
> --
> [image: Backbase] <https://backbase.com/>*Jon Meyler*
> Software Architect · R&D · Cardiff
> LinkedIn <https://www.linkedin.com/company/backbase> · Twitter
> <https://www.twitter.com/backbase> · Careers
> <http://careers.backbase.com/>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:36 p.m.
On Fri, Aug 9, 2019 at 10:31 AM Marek Posolda <mposolda(a)redhat.com> wrote:
Not sure about the switch for device functionality. Maybe we can add
it
later if there is a demand? Less switches is always good and removing
switches can be harder than adding them :)
I see your point, but this is something that you may not want to be enabled
OOTB.
IMO feedback from community will be interesting. I guess some people may
have issues that IP address won't work, because Keycloak is behind proxy
and admin don't have possibility to configure the proxy headers. Not
sure if such deployment, where administrator can't properly configure
proxy, exists and how much of them, but maybe some are...
I'm not sure too. A cookie/fingerprint approach to device identification
will also help in this situation.
10:57 a.m.
This needs to be simplified and not over engineered.
What we need is a permanent cookie that can identify the browser/agent on a
specific device. IP address should not be considered as a way to identify a
browser/agent/device as it simply won't work (IP changes, devices move,
multiple devices share same IP).
Further, there should be no separate storing of "devices" on the server
side. This should simply be attached to the existing user sessions. Add as
a note to the authentication session when that is created and add to the
user session when it is initially created. If I don't remember incorrectly
we actually already have a persisted cookie to prevent creating multiple
sessions from the same browser. If remember me is not on there is a
separate session cookie that can be used to invalidate an old session when
a new one is created. This prevents creating multiple session from the same
browser/device.
With regards to history of already logged out sessions the simple way to
solve that is to allow sessions to live around for a while after they have
been invalidated or logged-out. That should be a configurable option on a
realm on how long a session should be kept in history.
With regards to device fingerprinting for sure there are techniques that
can fairly accurately identify a browser (using a hash of all information
available to client-side js). However, that is overkill for what we are
trying to achieve. The simpler approach mentioned above with a cookie is
more than sufficient. If a user clears the cookies of a browser it'll just
end up with being listed as two sessions/devices.
Finally, bear in mind that devices is just a different view on to sessions.
That means that all sessions for the user should be visible in the devices
page. Not just some separate list of devices.
On Fri, 9 Aug 2019 at 22:30, Pedro Igor Silva <psilva(a)redhat.com> wrote:
On Fri, Aug 9, 2019 at 10:31 AM Marek Posolda
<mposolda(a)redhat.com> wrote:
> Not sure about the switch for device functionality. Maybe we can add it
> later if there is a demand? Less switches is always good and removing
> switches can be harder than adding them :)
>
I see your point, but this is something that you may not want to be enabled
OOTB.
>
> IMO feedback from community will be interesting. I guess some people may
> have issues that IP address won't work, because Keycloak is behind proxy
> and admin don't have possibility to configure the proxy headers. Not
> sure if such deployment, where administrator can't properly configure
> proxy, exists and how much of them, but maybe some are...
>
I'm not sure too. A cookie/fingerprint approach to device identification
will also help in this situation.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1725
days inactive
1738
days old
7 comments
5 participants
participants (5)
-
Federico Michele Facca -
Jonathan Meyler -
Marek Posolda -
Pedro Igor Silva -
Stian Thorgersen