On Tue, May 21, 2019 at 4:14 PM Jonathan Vanasco <jonat...@findmeon.com> wrote: > > Thanks for the kind words. This was actually pretty fast to do. I think it > took 2-3 days to build oAuth into our apps and almost everything was > repackaged into this within that same week. This has been sitting in a > private repo for a year or so, because it required some updates to oauthlib > and requests-oauthlib that I wrote but hadn't been merged/released yet. The > tough bit was getting the testing harness set up right. > > > I had written a lot of stuff explaining some things for you, and then > realized I may be all wrong in terms of what you're trying to accomplish. It > reads like you're trying to do a lot of different authorization things, but > then you specifically said no authorization but authentication. So I'm > getting tripped up a bit, especially by this line: "I don't need > authorization: just authenticating the user and retrieving their roles and > metadata and maybe the refresh feature" > > If the roles and metadata for the user are in Keycloak, then Keycloak is > handling the Authentication (e.g. the user authenticates to keycloak by > logging in) and you actually want Authorization to happen (which is what you > described above). > > So let's pull back for minute and get a better idea of what you're trying to > do in terms of use-cases. > > What is the intended interplay of your Keycloak server and your Pyramid > application?
I want it to do username/password checking and give me the user metadata including the list of roles. Then I can do authorization from the roles. By "no authorization" I mean the role/view ACLs would remain in Pyramid; I don't want to put them into Keycloak and ask it every page view whether this user has permission to this view. We decided to migrate our applications this way because authentication is the same across all web applications and Keycloak does it better, but authorization is application-specific and every Pyramid, Django, or other application has different needs and already has a working system. To tie the authentication and authorization together I need more user metadata than just the user ID. With LDAP, I fetch the user's OU property, and that indirectly tells what their group principals should be. I'm looking for something similar in Keycloak. > oAuth can be very annoying because one spec/project/initiative/framework > covers a handful of ways to implement it. The different implementation > methods are called "oAuth Flows" or "oAuth Grants". The first think you need > to do, is to decide exactly which grant you want do implement. Depending on > how you look at it, there are between 4 and 8 flows covered by a handful of > RFCs, all under the umbrella of oAuth. Yes, that's what's so complicated, trying to figure out which classes I need. I'm trying to implement the "Web Application Flow" in the 'requests-oauthlib' docs. So I would redirect to Keycloak, and it would authenticate the user and redirect back. I'm not sure what exactly to do after that. Keycloak would manage the user's account, password, whether the user can access this application, and a list of roles related to the application. -- 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 pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DupYrbog%2BhQukNKvROeyyzqxehcuiCWB1hDfjUnKqcxKAA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
