choria-io / aaasvc Goto Github PK
View Code? Open in Web Editor NEWChoria Centralized AAA Service
Home Page: https://choria.io
License: Apache License 2.0
Choria Centralized AAA Service
Home Page: https://choria.io
License: Apache License 2.0
aaasvc/signers/basicjwt/basicjwt.go
Lines 169 to 170 in 5b2adee
should be -1
To do this we need to support a blank ca certificate
Lines 63 to 69 in 07eabc0
Add a auditor that supports jetstream
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:
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
This was added to go-choria in choria-io/go-choria#1925 and we should reuse that
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
-rw-r--r--. 1 x x 580 Jan 30 17:52 .choria_token
is bad
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:
aaasvc/authorizers/actionlist/actionlist.go
Line 122 in b7fe8b7
should be agent.action not action.action
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"
Would sure be nice if it was possible to get a ticket via Kerberos/GSSAPI. Maybe could be done via SPNEGO?
Restarting the service just to add a user or change a password is lame
aaasvc/authenticators/okta/okta.go
Line 117 in 318c205
% ruby -c mcollective/application/login.rb <18:54:29
mcollective/application/login.rb:134: syntax error, unexpected end-of-input, expecting keyword_end
end
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.
Relates to choria-io/go-choria#1740
Token file should accept something like ~/.choria_token
this would end up in the token and allow for more flexibility in the OPA authorizer
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:
userlist
authenticator.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.
Some ideas for implementation that of course are open for discussion:
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.
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.
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.
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.
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.
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.
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.
caching prevent it from being updated via configmaps or secrets in kubernetes since its read once only
The ou claim will later be used by Choria multi tenenacy to put connections into specific accounts on the broker, should default to choria
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.