[keycloak-dev] User Device Activity

Fri Aug 9 09:31:07 EDT 2019

On 05. 08. 19 15:49, Pedro Igor Silva wrote:
> On Sat, Aug 3, 2019 at 7:49 AM Jonathan Meyler <jonathanm at 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 at 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 at 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 at 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 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
>>>
>>
>> --
>> [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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev