search

AzureAD / microsoft-authentication-library-for-go

The MSAL library for Go is part of the Microsoft identity platform for developers (formerly named Azure AD) v2.0. It enables you to acquire security tokens to call protected APIs. It uses industry standard OAuth2 and OpenID Connect.
MIT License
228 stars 87 forks source link

[Feature Request] Add dSTS support #467

Open bgavrilMS opened 9 months ago

bgavrilMS commented 9 months ago

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#L238

The 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.

  1. 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.

  2. As above, but change the tenant via WithTenant(T2). Ensure communication is now made over T2 endpoint.

  3. As 1, but make another request - ensure token comes from cache. Assert tokens cache keys.

chlowell commented 9 months ago

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)

Yes, that's the design: https://github.com/AzureAD/microsoft-authentication-library-for-go/blob/1f802fb142172e9fa7fbdfc1d19431b98e423e0d/apps/internal/oauth/resolvers.go#L47-L48

handsomejack-42 commented 8 months ago

I volunteer as tribute

handsomejack-42 commented 5 months ago

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 client_credentials (as per _Get a token for clientcredentials flow from dSTS), but tests referencing that do not seem to really cover what I am implementing.

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 AcquireTokenByCredential, is that sufficient? Should I call even AcquireTokenSilent for example?

Thanks.

bgavrilMS commented 5 months ago

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.