Questions about Federation and Remote Tokens

Concepts
1

First off, great appreciation for all the hard work done and continuing to be done on PrivacyIdea. While we haven’t been using it long and are still working towards production deployments, our initial impressions are very favorable. Kudos and good job!

Now, to the fun parts: understanding federations in v3.11. The documentation and how-tos are a bit thin in this area, and I accept that the short answer may be “go buy a support contract for Enterprise Support” – that’s OK, those wheels have been engaged and are (slowly) turning. In addition, I’ve browsed through the Github open issues and PRs and haven’t seen anything that addresses these questions.

In a nutshell, we’re looking to set up a scenario as described in the Federation Handler Module documentation – a “child” PI instance that can forward requests to “upstream” PI instances. We’re using Yubikeys if that is relevant. My explorations in this area have determined that this can and does work, albeit with some hurdles and annoyances:

  • Users need to be known in both PI instances. Understandable, but annoying and probably not possible to work around?
  • Users in the “child” instance need to have a Remote token assigned. Again, understandable, but several questions here:
    • Remote Serial is required to be set, but appears to be updated on first usage, so a value of 1 or similar appears to work? I may be confused here; lots of trials and explorations have occurred.
    • Check the PIN locally doesn’t appear to work (and isn’t changeable from the GUI once created). My explorations reveal that the PIN is checked on the child instance even if remote.local_checkpin is set to 0 in tokeninfo , and (of course) needs to match the parent instance. This is a major blocker and smells like a bug, but I haven’t dug into the code yet.

Any guidance here would be appreciated!

As an aside, I’ve found the PI container stack at GitHub - gpappsoft/privacyidea-docker: Simply deploy and run a privacyIDEA instance in a container environment. to be invaluable; I was able to incorporate those pieces into my containerized test environment with relative ease to explore federations with multiple PI instances.

thanks all,

–Chan

2

To be honest, the documentation about the Federation Handler is a bit thin, since it was never widely used. I am not sure if it left the stage of an idea at all.

It is worth to be noted, that the federation handler has nothing to do with remote tokens. A remote token works without the need to talk about federation.
A remote token is the virtual token, that points to another privacyIDEA system.
Every remote token could point somewhere else.
We often use a remote token to point to another token on the same privacyIDEA server of a different user. This is a simple workaround to allow to assign one physical token to several users.

The federation however is the idea, that certain requests can be forwarded to different privacyIDEA systems, without the need to look on the token basis.

However, this might fail in a lot of cases, since the evaluation of policies require much context, which might be missing in this case actually.
There is a lot room for discussion here.

I am sorry not to be able to give a more precise answer.