Analysis: Get Person API with lastname validation - caching of number of requests

[TheTechArch]

Description

In some apps there is a need for user to input ssn to give information about other parties.
In Altinn there is typical a requirement that if end user should be able to input the ssn to some other party he also needs to add the first 4 letters of the last name.

This so the solution not can be used to wash ssn.

Considerations

We need to identify how we ensure that a person number look up API can't be misused.

Caching

The most obvious mechanism for keeping a look up counter is some sort of caching. This needs to be a cache that can be used across as many apps as possible. There are 3 possible scopes:

• Global cache across all apps and app owners.
  For this issue we could consider a global cache a requirement. The idea is that there might be many apps across all app owners that are using the lookup. A global cache would then prevent misuse across all of them.
• Cache for all apps under one app owner.
  Counting all look ups triggered across the apps of each app owner might be enough to limit misuse.
• Cache for a single app. (Across multiple pods)
  Probably not broad enough for the case being discussed here. Though this point probably covers most of other caching needs?

It is also possible to create a custom cache client that hides the underlying service. The client can implement a type of scoping and add elements to a cache key to make the unique for a given scope. Maybe there is a need for a stronger wall between app owners, than the caching scope they set?

When it comes to the needs in this specific change the caching will be done by the Register platform component. This means we will need a caching mechanism available for the Platform. This will dictate what choices we make here. Another element is that we want to avoid relying too much on Azure specifically. Because of this the preferred hosting is as a container. We loose the built in monitoring.

Caching products

• Azure cache for Redis
  Managed Azure resource. Can easily be available for all apps across all app owners. Can alternatively have one for each app owner.
• Redis Docker container
  Redis can run in a docker container in any of our kubernets clusters. There could be one container i Platform for use as a global cache or there can be an instance running in each app owner cluster. https://hub.docker.com/_/redis
  Open source: https://github.com/redis/redis
• Memcached
  There are predefined images for Virual Machines on Azure, but no Managed resource offer. There are predefined docker images: https://hub.docker.com/_/memcached
  Open source: https://github.com/memcached/memcached

Feature	Redis	Memcached
Data types	String, Hash, List, Set, SortedSet	None (string)
Key sizes	512 MB	250 B
Value sizes	512 MB	1 MB
Scaling	Horizontal	Vertical
Volatile	No	Yes
Eviction policies	6 different	least recently used

Acceptance criteria

• There exist a API in register components where SSN and last name is given as input
• The API matches the 4 first letters in the last name to make sure that user is not guessing
• If it does not match a identity of the user should be used to cache a counter. If the number of errors exceeds 10 (todo: verify against current solution) the user should be blocked

Development tasks

• Build API operation
• Update client code

[lvbachmann]

Analysis of caching in W3-4

[altinnadmin]

A central server like for example redis? Redis can be set up as an Azure resource, or run as a docker container in a kubernetes cluster.

@TheTechArch Ref. Schrems II and local testing, we should avoid taking new direct dependencies on Azure resources. So we should prefer running it as a container if that's possible.

[SandGrainOne]

@altinnadmin I think the best caching product of those I've seen is Redis. Any thoughts on this?

[altinnadmin]

I think the best caching product of those I've seen is Redis. Any thoughts on this?

I agree 👍

[SandGrainOne]

@lvbachmann I've created two new issues for continued work:
#5621
#5623

[lvbachmann]

Analysis complete. Further work in separate issues.