-
Notifications
You must be signed in to change notification settings - Fork 46
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
Simple authorization support #14
Comments
Hello Daniel, thank you for reporting these issues and pointing out various ways we can improve Hologram. I actually had a JIRA ticket filed to investigate this, but didn't have the time before we pushed the open-source release out. 😺 It's a fantastic idea, and certainly the type of thing that belongs in Hologram, especialy if we want a larger audience for the system. A couple thoughts on this:
Ideally I would like to keep as little information in LDAP as I can, and push functionality to the IAM APIs. LDAP is already hard enough to administer, and AWS has built-in stuff for most of this. Tricky part is getting a nice, user-friendly face on it. You're definitely onto something. Interested to hear more thoughts. |
Sorry for my delayed response! I definitely agree with your About the authorization/LDAP point, I see where you're coming from but I also find it fairly appealing to manage user access in the LDAP server (where many other permissions for other services can be granted/revoked). For example, I'd love to just be able to add someone to a group in my directory and have them magically gain access to relevant IAM roles as well as anything that group entails on other services. Obviously, removal from that group would revoke their access to the credentials in question. It wouldn't be the end of the world if my workflow involved modifying the directory server and separately creating and permissioning IAM users, but it doesn't feel ideal either. Perhaps in environments with a less pervasive directory infrastructure, that's less compelling.
Out of curiosity, why did you store As far as a path forward, I feel fairly confident that I could implement the LDAP-based group authorization scheme I described above without much effort. If I were to implement it, I'd do so in a reasonably generic manner (user objects have a generic way to determine what roles they have access to) that could support an IAM-based alternative. I could submit such a thing in a PR and see if you'd be interested in it, but if you'd rather steer me in a direction more closely aligned with where you want to take it, I'm open to alternatives too! Perhaps the "user information" component ( Anyway, thanks again for the great project! |
No worries about delays - life has a way of catching up to us. Sounds from the other issues like you've been busy! 😺
Sort of. There's nothing in IAM that really allows us to store the information that we need. Perhaps making a SimpleDB table (something I considered, and am still considering for future improvements) with the I've been hesitant to put more info into LDAP because I honestly just couldn't figure out how to make an implementation of it that didn't require an inordinate amount of setup and maintenance when new roles were created, etc. I think I see what you're trying to go for with the groups, though:
I'll be very interested in seeing the PR for this.
Making that part of the
❤️ Thank you for all the excellent suggestions and helping us make Hologram more useful for more developers! |
What do you mean by policy documents? Why shouldn't it just be a list of roles a user is allowed to assume? |
Agh, I didn't think about that when I was reading through. Yes, you would want a list of those. For some reason I thought he wanted more granular permissions from the Still something worth looking into eventually, but not quite what's being called for here, it looks like. |
At the highest level, my goal is for different hologram users to have different access to different roles.
I don't know of the best way to do this, but off the top of my head, we could have a custom LDAP property that lists ARNs of roles the particular user is allowed to assume. Ideally the system would also be group-aware, and a user's access would be the union of the ARNs associated with the user's groups and the user's own special access.
Then, I think I would just type
hologram use arn:aws:iam::123456789012:role/mytest
(being able to enter full ARNs is nice for cross-account access) and have it just work.Is anything blatantly wrong with this? Can it be done more cleanly? Does it seem like the sort of thing that belongs in hologram?
The text was updated successfully, but these errors were encountered: