13/different realms #15
Conversation
| @@ -1,8 +1,6 @@ | |||
| [privacyidea] | |||
| # URL of your privacyIDEA installation | |||
| instance = http://10.0.0.1 | |||
| # Realm to use for authentication (may also be left blank) | |||
| realm = | |||
There was a problem hiding this comment.
We could still use a default realm, couldn't we?
There was a problem hiding this comment.
Yep! I thought it would be nice to have a "realm mapping" step analogously to the "user mapping" step.
Having one default realm could be achieved by the following config then:
[realm-mapping]
strategy = static
realm =
... so this is really just a modification of the config file layout.
example-proxy.ini
Outdated
| timeout = 3 | ||
|
|
||
| [preamble-cache] |
There was a problem hiding this comment.
Could we name this something like "application-cache", so that we know it is used with the different applications talking to the LDAP proxy?
There was a problem hiding this comment.
Hm yeah, maybe the naming is not very intuitive. My line of thinking was:
We call the LDAP search performed by the application prior to a LDAP bind a "preamble". The "preamble cache" remembers that a preamble happened for a specific timeframe. Specifically, it caches the DN of the queried user and the corresponding "app marker" (determined from the LDAP search filter, e.g. objectclass=App-<filter>).
The realm mapping strategy preamble can then use the preamble cache to determine the realm for a given bind request. For that, the realm-mapping section contains a mapping from app markers to privacyIDEA realms.
There was a problem hiding this comment.
Interesting. Why not call it something like "search-cache" in contrast to "bind-cache"?
(or app-cache?) ;-)
There was a problem hiding this comment.
I think "search cache" is a bit problematic, since we do not cache all LDAP search requests, but only the ones that contain an app marker. "App cache" is not entirely correct either, because we do not cache apps.
... so, naming is hard 😞 But I realize that inventing a lot of new words may overcomplicate everything. So I would probably go for "app cache"?
There was a problem hiding this comment.
Let's rethink this. Could this type of cache be used for something else than identifying the application? Then "app cache" might be a bit misleading or not general enough.
Generally speaking: The cache caches tuples of DNs and attribute values after a search - right? Is the realm mapping already applied? Then it rather might be a "realm cache" than an "app cache". Or an "attribute cache"....
There was a problem hiding this comment.
Well, the implementation is structured as follows:
If the preamble cache is enabled, the LDAP proxy monitors incoming search requests and their responses from the LDAP backend. If the request's filter contains an "app marker" (e.g. foo in (objectclass=App-foo) and the response contains exactly one entry, the tuple (dn, marker) is added to the preamble cache, from which it gets evicted automatically after a timeout.
Let's assume the user now enables the preamble realm mapping strategy. For an incoming bind request with a DN, the strategy queries the preamble cache. If there is a matching entry, the strategy retrieves the cached app marker and maps it to a realm (according to the [[mapping]] config section).
So, the preamble cache itself knows nothing about realms, it only stores DNs and app markers. Technically, the user could enable the preamble cache without using the preamble realm mapping strategy (althought the preamble cache would not be very useful in this case).
I propose the following: Internally, we keep the name "preamble" to describe the LDAP search prior to a bind request. We rename to "preamble cache" to "app cache" (which is a nice term, because it caches app markers). So the user never has to deal with the term "preamble".
example-proxy.ini
Outdated
| [preamble-cache] | ||
| enabled = true | ||
| timeout = 5 |
There was a problem hiding this comment.
We should add two timeouts for last_bind and first_bind. See #14. Maybe the naming also is not perfect, yet.
There was a problem hiding this comment.
Yep! They would however be part of the bind cache, not the preamble cache.
There was a problem hiding this comment.
Lets hope we do not need it at first.
example-proxy.ini
Outdated
| # Realm to use for authentication (may also be left blank) | ||
| realm = | ||
| # strategy = preamble |
There was a problem hiding this comment.
I like this. So "preamble" would be the "application-based" mapping.
There was a problem hiding this comment.
Exactly! i.e. the mapping strategy that uses the "preamble cache" for lookup. And we could easily implement other realm mapping strategies.
pi_ldapproxy/preamblecache.py
Outdated
| self.timeout = timeout | ||
|
|
||
| #: Map of dn to tuples (app marker, insertion timestamp) | ||
| self._preambles = {} |
There was a problem hiding this comment.
So the cache is only contained in the dictionary?
What about different processes and different threads?
We would not share the cache between different processes or even different machines.
Maybe we should use something like memcached or redis? Is this a huge overhead?
Working on #13
Creating Pull Request to be able to discuss things