-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add linked token resolution #9
base: master
Are you sure you want to change the base?
Conversation
This allows to pass the linked token without changing function signatures.
It can be retrieved with (*http.Request).Context().Value(websspi.LinkedTokenUserInfoKey).
Thanks, at first glance it looks good. Thanks for your effort! Will have more time to look it more detailed during the weekend. Noticed a buffer holding the SID is allocated with 50 bytes. May be it would be reasonable to preserve 68 bytes just for the SID as that seems to be the maximum byte size of a user SID. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be we should extend a bit the comment in the doc.go file. Something like that should do:
websspi package implements a middleware for SSO Kerberos authentication of HTTP requests in Windows environments by SSPI, without the need for any keytab files
@@ -0,0 +1,4 @@ | |||
/* | |||
Package websspi provides middleware to require with Windows Integrated Authentication. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be we should extend a bit the comment in the doc.go file. Something like that should do:
Package websspi provides middleware to require with Windows Integrated Authentication. | |
Package websspi implements a middleware for SSO Kerberos authentication of HTTP requests in Windows environments by SSPI, without the need for any keytab files |
&usedMemory, | ||
) | ||
|
||
tokenuser := (*TokenUser)(unsafe.Pointer(&buffer[0])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't really matter, but we could first check the value of err, before setting the value of the tokenuser variable
if a.Config.ServerName == "" { | ||
u.Groups, err = a.GetGroupsFromToken(linkedToken) | ||
} else { | ||
u.Groups, err = a.GetUserGroups(u.Username) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about this, but if u.Username
is same for both the original Token and the LinkedToken, there won't be need to check for the direct groups again.
GetLinkedUserInfo
is a new function, and if we agree that it does not need to be backwards compatible, you can make it completely ignore Config.ServerName
value.
By setting
(websspi.Config).ResolveLinked
there will be another*websspi.UserInfo
placed in the request context with the keywebsspi.LinkedTokenUserInfoKey
.The example is extended to return both, the regular and linked token (emphasis is not in the example):
If the same site is requested from an elevated command, the tokens are swapped. Tests and improved documentation is missing, hence the draft status of this PR.
Closes #5.