To help the server distinguish between provisioning tokens and client ids we should add a purpose field, for these we should use:

"purpose":  "choria_client_id"

should be -1

caching prevent it from being updated via configmaps or secrets in kubernetes since its read once only

Bit unfortunate that the intention was to run the server as aaasvc user, but then a el6 bug means its running as root and there's already a vast user base relying on that.

So el7 has to run as root too.

We should spike supporting OPA, the userlist might embed a rego policy into the JWT and the actionlist would evaluate the policy.

A sample policy might look like this:

package choria.aaa.policy

default allow = false

# user can deploy only frontend of myco into production but only in malta
allow {
	input.action == "deploy"
	input.agent == "myco"
	input.data.component == "frontend"
	requires_fact_filter("country=mt")
	input.collective == "production"
}

# can ask status anywhere in any environment but not unfiltered
allow {
	input.action == "status"
	input.agent == "myco"
        count(input.filter.fact) > 0
}

# user can do anything myco related in development
allow {
	input.agent == "myco"
	input.collective == "development"
}

this shows the user having access to all the various parts of a request - nothing about nodes as this is in the context of the signer - so just what is in the request.

Things we couldnt do before:

• authz on collective
• authz on filters being supplied or not
• authz on very specific filters
• authz on the inputs sent to the agent

Signature requests now include the Token (from login) and the Request, this is generally fine but essentially the token is a bearer token and we dont like bearer tokens.

To avoid this we should add a Signature to the SignRequest model that would be a signature made of the request using the seed file. This would be verified by AAA Service based on the public key in the token. This way we know the sign request is from the holder of the private key and not anyone who happen to have the JWT token.

Today the aaasvc only listens on 443, it's possible in recent Choria to have a Service on the network thats redundant, horizontally scalable and accessible over the Choria Broker, we should move to that to remove the 443 port for the signer and maybe the authenticator

Add a auditor that supports jetstream

should be agent.action not action.action

this would end up in the token and allow for more flexibility in the OPA authorizer

While testing this daemon with the action post authorized, I didn't set the agents claim properly. I was setting the agents claim as "agentname" instead of "agentname.foo". Was getting 502s, so I found out that there was an out of bounds element failure here:

Requirements

In our environment we have existing front-ends that provide Kerberos and OIDC authentication to users. These front-ends are already available and serving diverse back-ends running different services. What they do is to set some HTTP headers to be consumed by back-ends that can only talk to these front-ends. These headers contain information about the identity of the caller and are blindly trusted by the isolated backends.

Typically the front-ends are implemented with Apache using for instance mod_auth_openidc and mod_auth_gssapi although the technologies vary.

Hence, we'd like to contribute a patch to allow configuring aaasvc in a way that it delegates authentication to a trusted front-end by consuming for instance the REMOTE_USER HTTP header. This could be addressed by an userlist-like authenticator with a few changes where:

• No passwords will be stored whatsoever.
• Users known to aaasvc will be served the way they're served by the userlist authenticator.
• Optionally, tokens with a default profile containing default policies will be served for unknown users (not in the local DB).

In short, if aaasvc was configured this way, it would sign tokens for any user as presented by the front-end if there's a default profile, otherwise only for users explicitly declared in the local database.

This new feature could perhaps cover issue#33, as the caller could have the desired Kerberos support almost for free by configuring an Apache daemon in front.

Implementation ideas

Some ideas for implementation that of course are open for discussion:

Extend userlist.go

It's obvious that there are things in common between the already existing authenticator userlist and the one needed to implement the proposed change. As an initial idea, userlist could be patched in a way that, if a given config setting is enabled, it would ignore any user/password pair fed via /login and simply look at REMOTE_USER and continue. Other changes would be required to implement the optional no-user-found fallback explained above.

Write a new authenticator

Another obvious approach would be to write an authenticator from scratch, strongly inspired by userlist.go. It's not clear to me how it would fit with the existing URL handlers so perhaps it makes sense to evaluate separately using the existing API entrypoint or declare a new one for this.

1. Reuse (abuse) /login

   I haven't looked into detail but I imagine that, as things stand today, the way Swagger implements the API it'll make the request to fail if the user and the password are not fed. If we wanted to reuse this API entry point, that would have to be relaxed and the value of certain headers should be embedded into LoginRequest to be consumed by the authenticator, I guess.

2. Create a new API entrypoint (for instance /delegated_login)

   This would allow us to avoid overloading LoginRequest and have a separate model for this type of "lightweight" authentication request. However, I don't know if the code base is currently flexible enough to assign different authenticators to different API entrypoints. I haven't looked that deep, to be honest.

Write a generic userlist authenticator and extend it

Put the common functionality of both authenticators (user list lookups, claims generation, token building, etc) in a higher class and then subclass two implementations, namely userlistpasswd and userlistdelegated (just examples). API-wise, make /login work with any of these. I'm not familiar with Go so I don't know if this is possible.

Conclusions

As you can probably feel from my proposals, I'm not very familiar with the code base. That's precisely why I wanted to have a discussion first to see what would be in your opinion the most cost-effective way of action or even if this proposal makes any sense at all.

Restarting the service just to add a user or change a password is lame

• Use the new tokens package instead of MapClaims
• Add permissions

choria-io/go-choria#1509

Token file should accept something like ~/.choria_token

-rw-r--r--. 1 x x 580 Jan 30 17:52 .choria_token is bad

This was added to go-choria in choria-io/go-choria#1925 and we should reuse that

Relates to choria-io/go-choria#1740

The ou claim will later be used by Choria multi tenenacy to put connections into specific accounts on the broker, should default to choria

To do this we need to support a blank ca certificate

We need to be able to prevent people from harming the network by just doing a while true loop and hurting things.

We need a per user throttle, perhaps something that starts by giving them fast requests and then gradually slow down and also a service wide throttle to prevent 10 users from doing the same

Would sure be nice if it was possible to get a ticket via Kerberos/GSSAPI. Maybe could be done via SPNEGO?