ws authn ng

Chris Hyzer 11:30 PM
@gahaverkamp looking at your json log, Im wondering if you can explain your WS authn? I had added a note to the roadmap a little while ago about WS authn next generation. What are people's thoughts? Note, we will discuss this properly in the future... this is similar to SaaS systems do passwords
0. Note, that existing password schemes would still work in tandem with this, and you could disable this if you like :slightly_smiling_face:
1. We have a password table in the DB with encrypted passwords
2. Someone could create a local entity in the UI (with no privs)
3. That person who is an admin on the created (in their folder) local entity (which is like a group with non members) can create or change a password on it, and download it once and only once
4. That person could also setup/edit source IP addresses for the credential if they want
5. We have some sort of authentication scheme (is there a standard?) where we us encryption and dont send the password across the wire. we can look at how people currently do this. e.g. maybe the url and the current timestamp and the secret, all hashed together, also send the timestamp used which needs to be within tolerance to the current time. There can be a setting to allow replay (can easily make sure these are sequential and not reused)
6. Something like that which is more secure, self-serv, yet not a pain in the ass to use. The client can show the logic so people know they got it right
7. Of course people could grant READ or UPDATE to that local entity as needed
Thoughts? :slightly_smiling_face: (edited)
Greg Haverkamp 11:38 PM
@mchyzer Mine’s not quite where I want it to be yet — I guess we can all say that, huh? — but here’s what we do. I’ve added mod_auth_openidc to the ITAP image, using it in its OAuth2-only mode. We create local entities for WS clients that match their OAuth2 client_id, and for now, those clients must be configured with the grouper-ws scope in their metadata (and they must request it.)
Chris Hyzer 11:41 PM
hmmm
Greg Haverkamp 11:41 PM
That’s not my ideal end state. I’d love to pull my clients in as subjects directly, and while they’re stored in the directory, that’s not an officially sanctioned way to access them, so I’d ideally like a subject source via web services. (Though I guess I could write an LDAP proxy for it.).