-
Notifications
You must be signed in to change notification settings - Fork 88
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
[Feature Request] Add dSTS support #467
Comments
Yes, that's the design:
|
I volunteer as tribute |
Hey @bgavrilMS, I'm finally able to prioritize working on this issue (yay). I have made some changes, now I'm looking at Acceptance Tests section. I wanted to ask - is there an existing test I should mirror? Could you provide the link? I have been searching for In other words, the goal is to mock the response from dSTS endpoint using a mocked http server, then proceed with test cases mentioned in 1, 2, 3 re the Acceptance Tests section? in context of method calls, I'm going to do Thanks. |
For test 1, have a look at https://github.com/AzureAD/microsoft-authentication-library-for-go/blob/main/apps/confidential/confidential_test.go#L114 You should assert that:
This is for an SPN token. I am not sure you want to enable user auth. |
To support a new authority type, we need to evolve MSAL.GO to have a better abstraction for authorities. Today, MSAL.GO supports AAD and ADFS authorities.
How MSAL detects the authority type
MSAL parses the authority string to figure out the authority type. If the string ends in "adfs" it is an indication that it is ADFS authority.
For dSTS, there is also specific logic to figure this out - the first path segment is hardcoded to "dstsv2", e.g. "https://some.url.dsts.core.azure-test.net/dstsv2/tenantID"
Endpoint discovery
Unlike MSAL.NET, MSAL GO will actually figure out the token_endpoint and authorize_endpoint from the STS, via OIDC discovery (@chlowell to keep me honest). Some logic needs to be added for dSTS. Note that MSAL.NET hardcodes the endpoints.
https://github.com/AzureAD/microsoft-authentication-library-for-go//blob/cc89d3480721852bd00435ac0ce220d12c2cc8a3/apps/internal/oauth/resolvers.go#L122
Authority validation
Today, AAD authorities are validated through instance discovery. ADFS authorities are not validated. dSTS authorities are not validated (but we might define some rules later). Ideally we should have an abstraction for this.
WithTenant
MSAL Go allows app developers to update the authority via the
WithTenant
API. See https://github.com/AzureAD/microsoft-authentication-library-for-go//blob/cc89d3480721852bd00435ac0ce220d12c2cc8a3/apps/internal/oauth/ops/authority/authority.go#L238The logic must be updated to account for dSTS.
Acceptance Tests
We do not have E2E testing env for dSTS, so we have to rely on manual testing and unit testing.
Get a token for client_credentials flow from dSTS, using both "https://some.url.dsts.core.azure-test.net/dstsv2/tenantID" and "https://some.url.dsts.core.azure-test.net/dstsv2/common" authority. Rely on a mocked HTTP response. Please ping me for this response sample. Ensure instance discovery is not done.
As above, but change the tenant via
WithTenant(T2)
. Ensure communication is now made over T2 endpoint.As 1, but make another request - ensure token comes from cache. Assert tokens cache keys.
The text was updated successfully, but these errors were encountered: