WebApi Updated to latest Microsoft.Owin.Security.* packages and cannot find IIssuerSecurityTokenProvider inteface

[vazans]

Hi, I was running properly on protecting the WebApi with AD B2C AuthBearer token, after I upgraded to latest packages of Microsoft.Owin.Security.* I cannot find the definition for IIssuerSecurityTokenProvider anymore but when I try to use IIssuerSecurityKeyProvider instead of IIssuerSecurityTokenProvider I am running into a whole host of other issues.
Can somebody point me in the correct direction? specifically how Do I get the Owin setup part with code samples using the latest packages.

[vazans]

@parakhj @phatcher , I see both of you have a similar issue, Do you have any fix for this - Thanks

[phatcher]

@vazans The Azure B2C team are not very communicative - the roadmap is updated very infrequently and they don't keep us informed of what's happening at all.

They are also not very responsive to change in my opinion, e.g. we've been waiting for over 18 months for on-behalf of flows and we still have to use ADAL 2 to talk to Graph API which is well behind the current versioning.

I'd suggest reverting to the earlier libraries

[vazans]

Thanks @phatcher, I will revert back, we also updated the .net framework so might be a rats nest there trying to revert back just these packages.
@parakhj if you are listening Please help us out here, updating packages and no documentation on new packages make it really hard for me to trust this offering.
I will KEEP this one OPEN until get an actual resolution.

[parakhj]

I had noticed @phatcher's comment and flagged it. I have been working to get some resources committed to improving our samples. If there is a list of issues that you would urgently want fixed, please let me know. I can get those prioritized first

[vazans]

@parakhj nice to see you addressing issues, what I need urgently should be very simple, In the samples give here what needs to change after all packages are moved latest and .net is 4.7

@parakhj Please answer these simple 2 steps and this will save a ton of time.
Environment: .net 4.7/Web API 2.1/All packages updated to latest stable versions.

1. In file startup.auth.cs, how do we register an app for ADB2C Auth? What needs to change below?
   Note: IIssuerSecurityTokenProvider not available anymore
   public void ConfigureAuth(IAppBuilder app)
   {
   TokenValidationParameters tvps = new TokenValidationParameters
   {
   // Accept only those tokens where the audience of the token is equal to the client ID of this app
   ValidAudience = ClientId,
   AuthenticationType = Startup.DefaultPolicy
   };

        app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions
        {
            // This SecurityTokenProvider fetches the Azure AD B2C metadata & signing keys from the OpenIDConnect metadata endpoint
            AccessTokenFormat = new JwtFormat(tvps, new OpenIdConnectCachingSecurityTokenProvider(String.Format(AadInstance, Tenant, DefaultPolicy))) // This does not work
        });
    }
   

2. in file OpenIdConnectCachingSecurityTokenProvider.cs , how do we implement the replacement for IIssuerSecurityTokenProvider or other options

Thanks and marking this an URGENT Request,

[vazans]

I have put a detailed request of what I need above,
Can any one you help? @saraford @gsacavdm @microsoftopensource @rari2012 @spottedmahn @danieldobalian @parakhj - Reg How to use protect an .net WebApi 2.1(.net framework > 4.7) with AD B2C, The code shown in sample is outdated and does not work with latest packages, Please help.
I have given full details as comment above.

[spottedmahn]

Hi @vazans - I'm not sure exactly, sorry.

I do so this PR commit related to changing IIssuerSecurityKeyProvider.Tokens to IIssuerSecurityKeyProvider.SecurityKeys.

[spottedmahn]

Hi @vazans - I was able to get the TaskService updated. It compiles now but I haven't tested it yet.

The source code is here.

Apparently the package reference to Microsoft.IdentityModel.Protocol.Extensions is old. Source.

[spottedmahn]

Hi @vazans - I've updated the web app too. I've managed to test it and it appears to be working fine ⚡.

The branch with the changes is here.

[vazans]

Thanks @spottedmahn , will try this today and close when works.

[spottedmahn]

Cool @vazans. FYI, I submitted a cleaner PR #29 than the branch reference above.

[phatcher]

@spottedmahn @vazans I've managed to get my code working but my code uses the BootstrapContext to push the JWT token down to the API.

I noticed that there's a breaking change in that the identity's BoostrapContext is no longer a BootstrapContext but just the JWT token itself - is this intended or a bug in the Microsoft.Identity.Client code?

[spottedmahn]

Hey @phatcher - I'm not familiar w/ BootstrapContext. Seems like you doing this Access the JWT bearer token when using the JWT middleware in ASP.NET Core but in OWIN, correct?

[phatcher]

Once this change is committed I'll submit a PR to lift out some common code and improve the base ideas - I know this is a sample but it should be a bit cleaner.

[phatcher]

@spottedmahn Yes, that's correct, AFAIK that was the only way to do it in the earlier versions of the libraries

[phatcher]

Though technically I think it was the the WIF token that happens to be a JWT given the context i.e. you set TokenValidationParameters,SaveSigninToken = true and then it's available throughout the request, e.g.

public string AccessToken(ClaimsPrincipal principal = null)
{
    principal = principal ?? ClaimsPrincipal.Current;
    var cookieIdentity = principal.Identities.FirstOrDefault(x => x.AuthenticationType == "Cookies");

    if (cookieIdentity?.BootstrapContext is BootstrapContext context)
    {
        return context.Token;
    }

    return cookieIdentity?.BootstrapContext as string;
}

[spottedmahn]

@phatcher gotcha. Maybe posting an issue here: AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet would be a good idea as they are the creators of TokenValidationParameters.

Or maybe it would be a function of OWIN so posting here: aspnet/AspNetKatana would be a good idea? I'm not sure.

[spottedmahn]

Using idea 1 from here, you can add it as claim manually.

app.UseOpenIdConnectAuthentication(
                new OpenIdConnectAuthenticationOptions
                {
                    ...

                    // Specify the callbacks for each type of notifications
                    Notifications = new OpenIdConnectAuthenticationNotifications
                    {
                        ...
                        SecurityTokenValidated = OnSecurityTokenValidated
                    },
	     });

Add Claim on SecurityTokenValidated

Get IdToken Example

@phatcher

[phatcher]

I'm not sure that survives for the duration of the session or just for the request that authenticates it i.e. when I land on a new page in the same session TokenValidated won't be called again and I'm not sure whether user-assigned claims are persisted in the cookie; I went through something like this about 18 months ago when this first came out.

I've avoided scopes etc in the MVC app, apart from basic role checking, since I have to enforce it anyway in the API.

I'll try the first link - point is that it is a breaking change from the previous version, though I can see I will have fun when we go to .NET Core since IAuthenticationManager goes away so I'll have to revise the claims enrichment logic in the API

[spottedmahn]

It is getting persisted between requests. OnSecurityTokenValidated is only called once as you suspected. It must be writing this claim to the cookie then.

https://localhost:44316/Home/Claims

Source Code

[phatcher]

The BootstrapContext has been changed to a string due to .NET Core not having BootstrapContext - see AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#897

Would be nice to have some documentation/rationale as to why bother with the TokenCache etc in the MVC app rather than just pushing the JWT down to the API.

[phatcher]

@vazans @spottedmahn I remember why I didn't bother with tokens/scopes, the documentation https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oidc says that the only resource supported is the application itself...

"Currently, the only resource that you can request a token for is your app's own back-end web API. The convention for requesting a token to yourself is to use your app's client ID as the scope"

The example uses read and write scopes and validates them in the API, but this is a simple string match against the data in the scopes claim.

Couple of issues here....

• For any reasonable app you might have hundreds of scopes e.g. task.read, task.create, task.update, task.delete. This makes it infeasible to request everything at login
• Still can't return roles as claims from AAD B2C so we can't easily aggregate up to roles
• If we can use scopes, how do we define the valid ones in the AAD B2C tenant?

[vazans]

@spottedmahn @phatcher, I moved to other pressing priorities here at work, but I have a working code that I think should 1) works on latest packages, .net 4.7 2) work without Owin 3) separate Authen/Authorization essentially [Autorize] would only validate Authentication. Authorization can be custom based on claims in the prinicipal.
Not Tested this yet, so give me a week and I will post the tested code.
@phatcher for your questions
•Still can't return roles as claims from AAD B2C so we can't easily aggregate up to roles

Again, we are not Authorizing so not an issue. I need to test this but I thought we get all roles in the token. if NOT might need to use graph API call to your user/tenant to get the scopes assigned.
•If we can use scopes, how do we define the valid ones in the AAD B2C tenant?
I have done this, will let you know in a week when I post my changes.

[parakhj]

@spottedmahn helped us update the sample. Thanks @spottedmahn! Please check out the update and let me know if you find any other issues. Closing this one for the time being.

[Paqi]

@parakhj Can you point me to documentation about all the breaking changes, and migration instructions?