Thanks. This presents the same difficulty as 'pyramid_ouathlib', figuring out which parts I need. It's like looking through a forest for the right fern plants. My current authentication code and views is 4 pages long, the linked modules are 32 pages, and 'pyramid-oauthlib', 'ouathlib', and 'requests-ouathlib' are each around thirty pages of code and docs. Since these modules are only part of your library, I'm in awe of how much you know and wrote; it must have taken you weeks to figure it all out and write the code.
Let describe my current auth system, what I've accomplished on OAuth so far, and my assumptions so far of what a solution would look like. Then you can tell me whether my assumptions are correct. Current system: A. The Unauthorized view mimics the login form (username/password(, POSTing to the login view). B. The login view checks the username syntax, and either invokes LDAP (python-ldap3) to authenticate, or authenticates locally using a User database record. The LDAP result may cause the User record to be created or updated. C. The Pyramid group principles are calculated from the User record for authorization. D. It's using SessionAuthenticationPolicy with 'pyramid_redis_sessions'. E. We're moving to Keycloak because the LDAP server will be retired soon and Keycloak manages passwords better than the existing code. Oauth attempts: - I implemented the 'requests-oauth' console script and made a simple Pyramid application modeled after 'oauth2demo' from 'pyramid_oauth2_client'. Both of these instantiate a 'requests_ouathlib.OAuth2Session' and query the server for an authorization URL. - When I go to the URL, via redirect in the app or manually in the script, I get a kind of home page instead of an authentication dialog. This may be a problem with the server; I'm asking the server admins about that. Have you seen this before? - I need to get it to the point of successfully authenticating so I can see what user data it returns and whether it's sufficient. Assumptions about a solution: 1. The Unauthorized view will fetch an authorization URL and redirect to it. 2. Keycloak will authenticate the user, verify they're allowed to use this application, and return user metadata, including the user's roles. The roles are a list of strings and can be converted to Pyramid group principals for authorization. 3. The login view will receive this information and store the relevant parts in the session. 4. It can do authorization and property lookup from the session, so the User record may go away or be converted into a log of past logins and metadata. 5. If Keycloak accepts a nonce, I can pass it in step 1 and receive it in step 3 as a kind of CSRF token. 6. Do I need to do the third step and fetch an access token? Or is that just ito access a third-party resource (which I don't have any of). Where do I fetch the access token and what do I do with it? Will I want to refresh it? If so, where do I do that? Also, one of the docs somewhere recommended using an Authorizion: header, saying it was OAuth's preferred method. Is that compatible with a Pyramid workflow? Who sends the header to whom? Or is that again only for accessing third-party resources? How would I generate it and what should I do if I receive it? On Mon, May 20, 2019 at 2:46 PM Jonathan Vanasco <[email protected]> wrote: > > mike- > > if you haven't figured it out yet, hopefully my examples can help: > https://github.com/jvanasco/pyramid_oauthlib_lowlevel > > i've been meaning to release this for a while now, thanks for giving me a > reason to. > > in the tests, you can see a full flow of interacting with clients and servers: > > https://github.com/jvanasco/pyramid_oauthlib_lowlevel/blob/master/pyramid_oauthlib_lowlevel/tests/oauth2.py > > the client and server views are implemented in this file: > > https://github.com/jvanasco/pyramid_oauthlib_lowlevel/blob/master/pyramid_oauthlib_lowlevel/tests/oauth2_app/views.py > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/75af89f8-fb92-40e7-a014-aca324943e17%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DurFmeyu1n5hGUNEBin6%3DrhHwPZHSyVsWnkBY4zkq18mXg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
