-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add framework for authentication (authkit) and use it for local dev setup & test deployments #645
Add framework for authentication (authkit) and use it for local dev setup & test deployments #645
Conversation
This replace `login-handler.py`, which will be removed in future commits. It works slightly different as it takes the deploy ID as CLI arg instead of a socket path.
Since the login handler does not rely on `X-Accel-Redirect` anymore, we can remove parts of the nginx config.
9bfcd6a
to
f341336
Compare
1b6a4f4
to
f44e105
Compare
I think having this mode is very useful for multiple reason. For one, some organizations want exactly this auth-system and now don't need to build it themselves anymore. We wanted to be auth-system agnostic in Tobira, but I think it's fair to have an exception for Opencast as that is _the obvious_ system to support out of the box. Communication with Opencast is setup anyway. Moreover, I think this is a great starting point for anyone setting up Tobira. Because then, it's super easy to get Tobira auth up and running. Setting up the auth otherwise is usually fairly involved. And until then, you only have an empty Tobira and can't even add pages or blocks. So I think this vastly improves the initial setup experience. We are careful in describing this feature: there won't be any configurable behaviors about this. We just take the most obvious route and take exactly the data Opencast provides. Anything else needs to be done by writing your own login handler.
79d7ee6
to
bac2e97
Compare
bac2e97
to
be3ecd1
Compare
This is done to make them hopefully easier to understand and also to reflect the recent additions: `auth.mode = "opencast"` and the authkit.
e6f35c5
to
2302516
Compare
While the former is slightly nicer (because shorter), it's easier to just manage one NPM scope. From a user perspective it's also easier to "trust" just one scope instead of checking of `@tobira` is legit too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly language and style notes, but also some about the structure, which we talked about a bit already.
After some more thinking and reading I think the main thing that bugs me is the "User information Tobira needs" in the user login section. That doesn't belong there I think. Maybe put it in the "in depth" document?
And then yes, maybe move that to the end as we said, because that reads very much like a reference document.
Also maybe make it a bit clearer which parts are expected to be read by which users. Specifically maybe mention when ppl using the opencast
mode can stop. 🤔
c433998
to
cf1aa00
Compare
cf1aa00
to
544c7b6
Compare
Closes #550
See the referenced issue for motivation. Can be reviewed commit by commit, but reviewing all in one isn't bad either.
As you can see from the changes, our framework does more than the previous
login-handler.py
: it sends thePOST /~session
request to Tobira itself. That means noX-Accel-Redirect
magic is needed, making the nginx simpler.The main part is done, but this is still a draft for a number of reasons:
@opencast/tobira-authkit
auth.mode = "opencast-users"
. In that mode, Tobira would handlePOST /~login
requests itself by just asking Opencast if the login data is correct. That should be fairly easy to do. And I think it's very useful: it's the obvious auth system Tobira should support and I assume quite a few institutions want to use it. Further, even if an institution wants a different auth system in the long run, just using Opencast users is a very simple way to get everything running. Without auth system, you only see an empty Tobira which is quite underwhelming. So this would drastically improve the "first setup" experience IMO.I also noticed that we might want to simplify login handlers even more by adding yet another mode. In that mode, Tobira would forward-> I still think it's useful, but we won't do it now.POST /~login
requests to a configured HTTP service which would send back appropriate auth headers. This is little work in Tobira and that way, the nginx config could be a lot smaller still, again making it easier to set up Tobira.@tobira/authkit
for now.So yeah, I'd like to talk about the two additional auth modes and whether we want them. Of course they could be implemented in a separate PR. But it would also be nice to only needing to rewrite the docs once.