Skip to content
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

OAuth Server and Default Callback Support #246

Open
michaelrsweet opened this issue Sep 13, 2021 · 7 comments
Open

OAuth Server and Default Callback Support #246

michaelrsweet opened this issue Sep 13, 2021 · 7 comments
Labels
enhancement New feature or request priority-high
Milestone

Comments

@michaelrsweet
Copy link
Member

This bug is a placeholder for adding OAuth server support to cupsd and figuring out the right default callbacks on different platforms.

@michaelrsweet michaelrsweet added enhancement New feature or request priority-high labels Sep 13, 2021
@michaelrsweet michaelrsweet added this to the v2.5 milestone Sep 13, 2021
@michaelrsweet
Copy link
Member Author

Related to issue #100 which adds the basic client callback support in libcups.

@ShivanshCharak
Copy link

Okay so by authorization you mean when we open the localhost:631 it asks for username and password of the machine there we have to add authorization?

@michaelrsweet
Copy link
Member Author

@ShivanshCharak No, this is to integrate support for using OAuth/OpenID with CUPS - on the client side to open a browser window to authorize access, and on the server (cupsd) side to "introspect" the access token to get the authorized user name.

In short, an alternative to the usual username + password stuff.

@yarons
Copy link

yarons commented Mar 2, 2023

It's easier to manage from security perspective by allowing having a single identity per employee and auditing (SAML is a good example, think about controlling the paper type and color/b&w centrally in that case).
OpenID Connect is usually for public services authentication such as Google, Facebook, etc., I don't think it's mandatory for such project.

@ShivanshCharak
Copy link

@michaelrsweet okay so you mean by using openid we have to do Authorization by poping up the window there we have to give our detail like email or password and by using tge system will give us access

@michaelrsweet
Copy link
Member Author

@ShivanshCharak I appreciate the enthusiasm!

We are finalizing some OAuth things over in the Printer Working Group now, and I hope to post an initial document for discussion this week (I'll add a link here).

Aside from the logistics of what bits of OAuth/OpenID to support, there are also a bunch of security things to think about in implementation to prevent arbitrary programs from collecting access tokens.

@michaelrsweet
Copy link
Member Author

michaelrsweet commented Apr 5, 2024

OK, so I've been noodling some things for how to implement this:

  • Add an Authorization header store per FQDN (like the "ssl" directory, but for OAuth) with a simple API for getting/setting/clearing tokens
  • Also support a CUPS_HTTP_AUTHORIZATION environment variable to specify the Authorization: header to use for non-interactive usage
  • Add a command (cupsoauth?) to manage the encrypted store (get/set/clear)
  • Add cupsd support for OAuthServer URI directive and AuthType Bearer value to cupsd.conf, with requirement for OpenID/RFC 8414 metadata and JWT usage so that tokens can be introspected locally

For GUI applications, the CPDB UI will need to handle bringing up the OAuth authorization page and collecting the bearer token.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority-high
Projects
None yet
Development

No branches or pull requests

3 participants