Is it possible to ignore unknown scopes in IdentityServer4? - identityserver4

I have an app using the Microsoft.AspNetCore.Authentication.OpenIdConnect package to authenticate against a server using IdentityServer4.
In the IdentityServer implementation, I have the standard set of scopes set up as IdentityResource.
return new List<IdentityResource>
{
new IdentityResources.OpenId(),
new IdentityResources.Profile(),
new IdentityResources.Email(),
new IdentityResources.Address(),
new IdentityResources.Phone()
}
I want to add a new Identity Resource with a new scope to provide information. To test out backwards compatibility, I added the new scope in my app's AddOpenIdConnect callback:
.AddOpenIdConnect(options => {
// snipping for brevity
options.Scopes = new[] {
"openid",
"profile",
"my-new-scope" // <- Does not exist in Identity Server yet.
};
})
According to the OpenId Connect Core specification - scopes that unknown to the OpenId Provider should (emphasis theirs) be ignored. But when I try to authenticate, I get an invalid_scope error.
Is there a way to tell IdentityServer to ignore scopes it doesn't know about?

Related

How to access external provider's access token at OnRedirectToIdentityProviderForSignOut of OpenIdConnectEvents with IdentityServer4?

My application need to integration with a custom Identity provider that does not support end_session_endpoint.
However it does support SLO by using the URL such as
https://idp.example.com/logout?token={access_token_or_refresh_token}&goto={post_logout_redirect_url}
I have figured to setup the custom URL through
options.Events = new OpenIdConnectEvents
{
OnRedirectToIdentityProviderForSignOut = context =>
{
context.ProtocolMessage.IssuerAddress = "https://idp.example.com/logout";
context.ProtocolMessage.SetParameter("goto", context.ProtocolMessage.PostLogoutRedirectUri);
return Task.CompletedTask;
}
};
But I could not figure out how to gain access to the access token of the external provider and set it through SetParameter.
Any help will be appreciated. Thanks.
I have tried setting breakpoint at the event and there is not much information other than id_token_hint in the parameters.

Identity Server 4: RequestedClaimTypes in IProfileService.GetProfileDataAsync not including IdentityResourceClaims

I have created my own ProfileService concrete, based on the built in one.
in GetProfileDataAsync(), context.RequestedClaimTypes does not include any related claims from IdentityResourceClaims table, but it does have the IdentityResource from the specified scopes in context.RequestedResources.ParsedScopes. I would think the claims associated with those scopes should be included in RequestedClaimTypes, otherwise is there any way to get these from the context? Or would I need to do my own db query?
Is this example - "app_perms" is the scope (identity resource) and "app" is the related claim (in the IdentityResourceClaims table)
protected virtual async Task GetProfileDataAsync(ProfileDataRequestContext context, IdentityUser user)
{
// since not including claims for IdentityResource scopes, need to check the scope
if (context.RequestedResources.ParsedScopes.Any(x => x.ParsedName == "app_perms") || context.RequestedClaimTypes.Contains("app"))
{
// add some test app claims
context.IssuedClaims.Add(new Claim("app", "App1"));
context.IssuedClaims.Add(new Claim("app", "App2"));
}
}
My impression is that you just set all the available claims in GetProfileDataAsync and then let IdentityServer to decide what claims should end up in the different places (id/access token, userinfo....)
This also simplifies the implementation of the IProfileService
Actually they can be found here:
context.RequestedResources.Resources.IdentityResources.Any(x => x.UserClaims.ContainsIgnoreCaseTrim("role"))

Add additional query parameters to the Azure B2C login url

I'm implementing Azure B2C to a .NET MVC app, and I need to add an extra query parameter to the login url.
Here's how I've set it up in the startup.cs
var openIdConnectAuthenticationOptions = new OpenIdConnectAuthenticationOptions
{
// Generate the metadata address using the tenant and policy information
MetadataAddress = String.Format(Globals.WellKnownMetadata, Globals.Tenant, Globals.DefaultPolicy),
// These are standard OpenID Connect parameters, with values pulled from web.config
ClientId = Globals.ClientId,
RedirectUri = Globals.RedirectUri,
PostLogoutRedirectUri = Globals.RedirectUri,
// Specify the callbacks for each type of notifications
Notifications = new OpenIdConnectAuthenticationNotifications
{
RedirectToIdentityProvider = OnRedirectToIdentityProvider,
AuthorizationCodeReceived = OnAuthorizationCodeReceived,
AuthenticationFailed = OnAuthenticationFailed
},
// Specify the claim type that specifies the Name property.
TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name",
ValidateIssuer = false
},
// Specify the scope by appending all of the scopes requested into one string (separated by a blank space)
Scope = $"openid",
ResponseType = "id_token",
};
app.UseOpenIdConnectAuthentication(
openIdConnectAuthenticationOptions
);
And when someone tries to visit an [authorized] tagged page, it sends them to this b2c url:
https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_custom_signin&client_id=0000-000000-000-00&redirect_uri=https://localhost&response_type=id_token&scope=openid&x-client-SKU=ID_NET461&x-client-ver=5.3.0.0
However, I need to add an extra query parameter onto the end, "&appId=000-000-000", so the resulting login URL is:
https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_custom_signin&client_id=0000-000000-000-00&redirect_uri=https://localhost&response_type=id_token&scope=openid&x-client-SKU=ID_NET461&x-client-ver=5.3.0.0 &appId=000-000-000
how would I go about doing this?
I'm afraid you could not add the appId parameter, but I recommend to make use of the state parameter. You could use this parameter to send the value of appid as part of request and it gets returned back in response.
For more details, see here.

Azure AD v2.0-specific optional claims missing from ID Token

I'm trying to add optional claims using Microsoft Identity Web - NuGet for user authentication in NET Core 3.1 WebApp. Reading the MS Docs, it seems that the only steps needed are to declare the optional claims within the App Registration Manifest file in Azure. But when testing the login process using two different apps (my own code and an MS project example) it looks like the optional claims are not being added to the ID Token when returned from Azure following a successful login i.e they're not present at all when viweing the token details in Debug.
I'm not sure how to diagnose this and where to trace the issue i.e am I missing any required steps in Azure setup?
Side Note: Just to confirm it is the jwt ID Token I want to receive the additional claims, NOT the jwt access token used for calling the graph or another Web API endpoint.
MS Docs reference: v2.0-specific optional claims set
Below is the extract from the Manifest file: (note I've even declared the "accessTokenAcceptedVersion": 2, given that optional claims I'm using are not available in ver.1, which if the above was left at default 'null' value then Azure will assume we're using legacy ver.1 - a possible gotcha)
"accessTokenAcceptedVersion": 2,
"optionalClaims": {
"idToken": [
{
"name": "given_name",
"source": "user",
"essential": false,
"additionalProperties": []
},
{
"name": "family_name",
"source": "user",
"essential": false,
"additionalProperties": []
}
],
"accessToken": [],
"saml2Token": []
},
Extract from startup class:
public void ConfigureServices(IServiceCollection services)
{
// Added to original .net core template.
// ASP.NET Core apps access the HttpContext through the IHttpContextAccessor interface and
// its default implementation HttpContextAccessor. It's only necessary to use IHttpContextAccessor
// when you need access to the HttpContext inside a service.
// Example usage - we're using this to retrieve the details of the currrently logged in user in page model actions.
services.AddHttpContextAccessor();
// DO NOT DELETE (for now...)
// This 'Microsoft.AspNetCore.Authentication.AzureAD.UI' library was originally used for Azure Ad authentication
// before we implemented the newer Microsoft.Identity.Web and Microsoft.Identity.Web.UI NuGet packages.
// Note after implememting the newer library for authetication, we had to modify the _LoginPartial.cshtml file.
//services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
// .AddAzureAD(options => Configuration.Bind("AzureAd", options));
///////////////////////////////////
// Add services required for using options.
// e.g used for calling Graph Api from WebOptions class, from config file.
services.AddOptions();
// Add service for MS Graph API Service Client.
services.AddTransient<OidcConnectEvents>();
// Sign-in users with the Microsoft identity platform
services.AddSignIn(Configuration);
// Token acquisition service based on MSAL.NET
// and chosen token cache implementation
services.AddWebAppCallsProtectedWebApi(Configuration, new string[] { Constants.ScopeUserRead })
.AddInMemoryTokenCaches();
// Add the MS Graph SDK Client as a service for Dependancy Injection.
services.AddGraphService(Configuration);
///////////////////////////////////
// The following lines code instruct the asp.net core middleware to use the data in the "roles" claim in the Authorize attribute and User.IsInrole()
// See https://learn.microsoft.com/aspnet/core/security/authorization/roles?view=aspnetcore-2.2 for more info.
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
// The claim in the Jwt token where App roles are available.
options.TokenValidationParameters.RoleClaimType = "roles";
});
// Adding authorization policies that enforce authorization using Azure AD roles. Polices defined in seperate classes.
services.AddAuthorization(options =>
{
options.AddPolicy(AuthorizationPolicies.AssignmentToViewLogsRoleRequired, policy => policy.RequireRole(AppRole.ViewLogs));
});
///////////////////////////////////
services.AddRazorPages().AddMvcOptions(options =>
{
var policy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
options.Filters.Add(new AuthorizeFilter(policy));
}).AddMicrosoftIdentityUI();
// Adds the service for creating the Jwt Token used for calling microservices.
// Note we are using our independant bearer token issuer service here, NOT Azure AD
services.AddScoped<JwtService>();
}
Sample Razor PageModel method:
public void OnGet()
{
var username = HttpContext.User.Identity.Name;
var forename = HttpContext.User.Claims.FirstOrDefault(c => c.Type == "given_name")?.Value;
var surname = HttpContext.User.Claims.FirstOrDefault(c => c.Type == "family_name")?.Value;
_logger.LogInformation("" + username + " requested the Index page");
}
UPDATE
Getting closer to a solution but not quite there yet. Couple of issues resolved:
I originally created the Tenant in Azure to use B2C AD, even though I was no longer using B2C and had switched to Azure AD. It wasn't until I deleted the tenant and created a new one before I started to see the optional claims come through to the webapp correctly. After creating the new tenant and assigning the tenant type to use Azure AD, I then found that the 'Token Configuration' menu was now available for configuring the optional claims through the UI, it seems that modifying the App manifest is still required as well, as shown above.
I had to add the 'profile' scope as type 'delegated' to the webapp API Permissions in Azure.
The final issue still unresolved is that although I can see the claims present during Debug, I cant figure out how to retrieve the claim values.
In the method below, I can see the required claims when using Debug, but can't figure out how to retrieve the values:
public void OnGet()
{
var username = HttpContext.User.Identity.Name;
var forename = HttpContext.User.Claims.FirstOrDefault(c => c.Type == "given_name")?.Value;
var surname = HttpContext.User.Claims.FirstOrDefault(c => c.Type == "family_name")?.Value;
_logger.LogInformation("" + username + " requested the Index page");
}
Debug Screenshots shows the given_name & family_name are present:
I've tried different code examples using the claims principal to try and get the values out, but nothing is working for me. Hoping this final riddle is fairly simple to someone who knows the required syntax, as said we now have the required optional claims present, its just not knowing how to actually get the values out.
Big thanks to 'Dhivya G - MSFT Identity' for their assistance (see comments below my original question) method below now allows me to access the required claim values from the Token ID returned from Azure following successful login.
public void OnGet()
{
var username = HttpContext.User.Identity.Name;
var forename = HttpContext.User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.GivenName)?.Value;
var surname = HttpContext.User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Surname)?.Value;
_logger.LogInformation("" + username + " requested the Index page");
}

Identity server claims asp.net API

I'm currently writing an angular application that first authenticates against think texture identityserver3.
This works fine, and I receive the bearer token without any issues.
When I use my token on an call to my API, I'm authenticated. I can see my userid, but have lost my claims (username, roles,...).
What do I have to do for transferring my claims with my token, or getting the roles from the identityserver?
You can tell Identity Server to include specific claims in an access token by adding that claim to your API's Scope.
Example:
var apiScope = new Scope {
Name = "myApi",
DisplayName = "My API",
Type = ScopeType.Resource,
Claims = new List<ScopeClaim> {
new ScopeClaim("myClaimType")
}
};
You can also use the AlwaysIncludeInIdToken property of ScopeClaim to include the claims in identity tokens as well as access tokens.
See https://identityserver.github.io/Documentation/docsv2/configuration/scopesAndClaims.html for more info.
We are doing something very similar using MS Web API 2 and a Thinktecture Identity Server v3.
To verify the user's claims we created an Authentication Filter, and then called the Identity server directly to get the user's claims. The bearer token only grants authentication and it is up to the API to get the claims separately.
protected override bool IsAuthorized(HttpActionContext actionContext)
{
string identityServerUrl = WebConfigurationManager.AppSettings.Get("IdentityServerUrl") + "/connect/userinfo";
using (var httpClient = new HttpClient())
{
httpClient.DefaultRequestHeaders.Authorization = actionContext.Request.Headers.Authorization;
var response = httpClient.GetAsync(identityServerUrl).Result;
if (response.IsSuccessStatusCode)
{
string responseString = response.Content.ReadAsStringAsync().Result;
Dictionary<string, string> claims = JsonConvert.DeserializeObject<Dictionary<string, string>>(responseString.ToLower());
... Do stuff with your claims here ...
}
}
}

Resources