You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some back-end primary authentication services (i.e. Okta) can provide a profile image for a user. It would be cool if Keymaster could grab this information and pass it along to downstream consumers such as Web Service Providers (SPs).
If the back-end provides a URL to the profile image, that could be passed along as-is. However, if the back-end provides the image data inline then Keymaster must store the image data. The database used for managing U2F tokens is a good place for this, as these data are already automatically replicated to Keymaster instances. Since images can be large, they should be capped in size and transcoded prior to storage to prevent excessive growth of the database.
Even if the back-end provides a URL, it may be preferable to grab the data, cap and transcode it so that internal systems can obtain the profile information without having to connect to the back-end. This would enhance privacy and resiliency.
The text was updated successfully, but these errors were encountered:
What about if we start using gravatar images profiles?
We will not store any extra data on the db.. instead we compute the user's hash and download to a local filesystem cache within each keymaster?
So new handler:
func getimage
compute gravatar hash (based on email)
if on cache and fresh
return cached
downloadFrom gravatar.
if timeout or err
if stale cache:
return stale image
return default image (we will create)
update cache
return freshly cached image
Some back-end primary authentication services (i.e. Okta) can provide a profile image for a user. It would be cool if Keymaster could grab this information and pass it along to downstream consumers such as Web Service Providers (SPs).
If the back-end provides a URL to the profile image, that could be passed along as-is. However, if the back-end provides the image data inline then Keymaster must store the image data. The database used for managing U2F tokens is a good place for this, as these data are already automatically replicated to Keymaster instances. Since images can be large, they should be capped in size and transcoded prior to storage to prevent excessive growth of the database.
Even if the back-end provides a URL, it may be preferable to grab the data, cap and transcode it so that internal systems can obtain the profile information without having to connect to the back-end. This would enhance privacy and resiliency.
The text was updated successfully, but these errors were encountered: