Claims management for authz #47
Conversation
1. Add default admin authorization for built in admin user. 2. Add principals claim to login token to represent local user/ldap groups associated with a AD user 3. Use authorizations to add role claim to token that is used by UI for role differentiation 4. Use authorizations to generate role claim at runtime to perform RBAC on API calls
| switch { | ||
| // If no authorizations are found, this user has not been authorized to | ||
| // access any resources yet. Return success without adding the claim. | ||
| case l == 0: |
There was a problem hiding this comment.
I guess this only means that there is no role=whatever is added for the principal, but the principal may have tenant authZs defined. Am I right?
There was a problem hiding this comment.
How are we expecting the UI to treat a token with no role?
There was a problem hiding this comment.
Return an error message saying "you are not authorized. Go talk to Admin and get access to something first"
There was a problem hiding this comment.
role=whatever authorization will be added automatically (will come in next PR) whenever the tenant authz is added.
| case l == 0: | ||
| return nil | ||
|
|
||
| default: |
There was a problem hiding this comment.
l>1 if more than one role authZ is defined for the user. e.g. role=admin, role=ops? Shouldn't we handle that or Are we restricting it to be only 1 at any point?
There was a problem hiding this comment.
No, there is only 1. The goal is to "cache" the highest role available. It is only really useful when you are working with global access roles such as admin. For most RBAC impl., we will be looking for tenant authz with specific roles.
| } | ||
|
|
||
| // If not a valid role, ignore error and move on to next principal | ||
| r, err := types.Role(authz[0].ClaimValue) |
There was a problem hiding this comment.
How are we assuming len(auth)<=1 always?
There was a problem hiding this comment.
See above. There will be only 1 claim of type role, if any.
| return types.Authorization{}, err | ||
| } | ||
|
|
||
| log.Info("Adding role authorization successful") |
There was a problem hiding this comment.
Can we log a few more deets here, like the principalName and role? Not sure how much value this line adds currently
There was a problem hiding this comment.
Good point. Let me clean it up in my next PR.
| tmp, ok := auth.(*types.Authorization) | ||
| if ok { | ||
| if (tmp.ClaimKey == claim) && (tmp.PrincipalID == ID) { | ||
| if (tmp.ClaimKey == claim) && (tmp.PrincipalName == principal) { |
There was a problem hiding this comment.
The parentheses here are unnecessary and can be removed
|
@rhim Are you not supposed to change https://github.com/contiv/ccn_proxy/blob/c914de1c31337fcf3e0826c01f951d5f1b7fbb5b/auth/policy.go#L61 in this PR? |
|
Next PR :-).
- Himanshu
.:|:.:|:.
On Dec 16, 2016, at 12:03 PM, Yuva Shankar <notifications@github.com<mailto:notifications@github.com>> wrote:
@rhim<https://github.com/rhim> Are you not supposed to change https://github.com/contiv/ccn_proxy/blob/c914de1c31337fcf3e0826c01f951d5f1b7fbb5b/auth/policy.go#L61 in this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#47 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMiMKeyi_1tE-ESZP9dTnnvpCB9DH1tdks5rIu6bgaJpZM4LO9NY>.
|
3 participants
groups associated with a AD user
role differentiation
on API calls