SP4 beta1 + Hub 0.0.3 PoC

[Scott Cantor]

Thank you. I haven't tested with LDAP with any seriousness, nor has anybody else obviously, so ths is helpful. Most of the issues are simple to correct and I'll work on unit tests for the LDAP scenario.

> Suggest the hub either ship its own filter policy file or document that the IdP's default filter applies to hub attribute release.

Both Basics topics on SAML and OIDC mention this, and that there's an example policy in conf/examples/attribute-filter-sp.xml

The plugin cannot overwrite the IdP's default file (I mean, it could physically I suppose, but it's not going to).

I intend to produce a more full discussion of Attribute handling but since I don't even really know how/when the resolver would get used (and it will need some polishing on that front), I'm not jumping the gun writing much on that yet.

> Same install also logs `ResolutionException: Attribute Definition 'uid': provided principal name was empty` on every login from the stock resolver — cosmetic, but noisy.

I have to assume that's only if the resolver were being run, which isn't typical. I'll have to ask Phil about it, it could be that the OIDC plugin is actually forced to run it for some reason or is accidentally doing so.

Again, the IdP defaults aren't suitable, but I'll likely produce some kind of skeletal example for the SP as I did for the filter.

Notably, the identity of a principal in the resolver is impossible for the SP to supply apriori, it requires configuration by somebody to tell the SP where the "principal" comes from, and the hook for that is still just an open slot so that has to get documented and examples built.

The old SP only had a resolver in the sense that it was used to perform SAML queries to Attrbute Authorities and that isn't a routine use case. It will be supported, but the code for that is very fresh in the IdP and has not been fully tested.

>     • `p:usernames` cannot work with an external validator.

I'll review all that code and make sure the tests run that case.

>     • Agent has no username setting independent of `agentID`. RemotingSettings confirms `agentID` is "the 'username' used by the Agent when connecting to the Hub"; there's no `secretUsername`-style knob. Fine if #4 is fixed hub-side, but worth stating in the docs since the ACAMP conversation implied agents could present different credentials over time.

If it needs more clarification I'll work on it, but the Agent's agentID setting is indeed the username, period. The Hub's notion of that is indirect if they don't match and it becomes solely a logging artifact.

>     • IdP installer ignored `idp.host.name` for the Jetty keystore under Docker.

I would suggest filing an independent bug on that, but in actual fact that's largely historical anyway, I would imagine we will drop all that for V6 and leave it to the Jetty plugin. I would definitely tell anybody doing any kind of mock up to just script it themselves.

> agent→hub responses are always HTTP 200 with the outcome in the DDF body, which is worth a sentence in the agent docs since a naive health check on status codes sees nothing.

I'm not sure what would be looking at them. The technical documentation should (and I think maybe does) mention it, but that's aimed at Agent developers.

There are some tracing capabilities but they're not well documented yet.

>     • Agent list format. The thing that made the LDAP model pleasant was that `agents.xml` became trivial — id, address range, authentication method, nothing secret. If the v1 flat file is "AgentID + optional credential" and the directory holds the credential, then the flat file is really just an allow-list, and generating it from the directory (or from an IGA tool that owns the service accounts) is a few lines. I'd rather see that than a hub-side database with a GUI, at least to start.

It would be more likely that I'd want to define a schema for Agents in LDAP and actually build a source plugin that loads them from a directory, not so much with an extra hop of a file to just say "here they are".

But in practical fact, while you might prefer that, the world simply won't. Directories failed pretty soundly as application repositories, and I think the audience for that feature would be incredibly small. But I am happy to be persuaded otherwise.

My experience is that the fastest two "NO"s in IT are from the DNS team and the LDAP team when the question starts with "I'd like to put X in there".

But it's probably not a ton of work regardless, just not on the front burner.

>     • Who owns the username. Right now the identity the hub logs (`p:id`) and the identity the agent presents (`agentID`) are the same string in practice (#4/#5).
> If the intent is that they diverge — service account rotates, agent identity doesn't — it would help to say so explicitly in the model, because the current code enforces the opposite.

That's simply a bug.

-- Scott