Identityserver4: 2.0 breaking changes list

Created on 12 Apr 2017  路  31Comments  路  Source: IdentityServer/IdentityServer4

  • GrantTypes.List removed in favor of ICollection<string> for Client.AllowedGrantTypes
  • Stores no longer expected to remote stale items; no longer check expiration; #1135
  • Add reminder that DI order is also important (e.g. they want to customize cookies)
  • federated signout is now different
  • now using default authN scheme
  • AddTemporarySigningCredential => AddDeveloperSigningCredential
  • PublicOrigin
  • IResourceStore.GetAllResources => IResourceStore.GetAllResourcesAsync
  • New Client properties:

    • FrontChannelLogoutUri

    • FrontChannelLogoutSessionRequired

    • BackChannelLogoutUri

    • BackChannelLogoutSessionRequired

    • ConsentLifetime

  • GetIdentityServerUserAsync gone
  • AddRequestedClaims/FilterClaims APIs for profile service
  • IClientSession to IUserSession
  • Client claims prefix
  • rename ClientAssertionSecretParser to JwtBearerClientAssertionSecretParser

no breaking - but needs docs

  • AppAuthUriValidator
  • Config schema
docs

Most helpful comment

@brockallen what should we use instead of GetIdentityServerUserAsync? Is it just HttpContext.User? thank you so much

All 31 comments

Are there any other changes to 2.0?

I thought the "pseudo"-typed GrantTypes.List was there to prevent people from choosing allowed granttypes that could result in unfavorable scenarios from a security perspective.

and that is still the case...

Add AppAuth redirect URI validator

Add "schema" and docs for clients and resources from config

I have the following issue:
Reference to type 'AuthenticationOptions' claims it is defined in 'Microsoft.AspNetCore.Authentication', but it could not be found.

here: app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions...

I have:
"IdentityServer4" Version="2.0.0-preview4"
"IdentityServer4.AccessTokenValidation" Version="1.2.1"

@vitalbsk this is a standard issue in .net -- you need to add a direct reference to the assembly

Have a call to HttpContext.GetIdentityServerUserAsync() but getting a build error. Started happening post asp.net core 2.0. I believe this is the thread to add the issues too? Error: HttpContext does not contain a definition for GetIdentityServerUserAsync and no extension method GetIdentityServerUserAsync accepting a first argument of type HttpContext

Yep, it's gone.

@brockallen I cannot add the direct reference IdentityServer4.AccessTokenValidation.dll:
"The reference is not valid or unsupported".

I added the project "AccessTokenValidation" to my solution and added it as a reference to my project then and I have the same issue:
Reference to type 'AuthenticationOptions' claims it is defined in 'Microsoft.AspNetCore.Authentication', but it could not be found.

I don't know why it doesn't work. I see extension method in your project but I have no idea why it cannot find it.

We've not yet updated the token validation middlewares.

@brockallen thanks. Let us know then. Appreciate your product

@brockallen what should we use instead of GetIdentityServerUserAsync? Is it just HttpContext.User? thank you so much

Yes, HttpContext.User or HttpContext.AuthenticateAsync

This is missing .AddAspNetIdentity<ApplicationUser>() maybe it's not needed, but if this thread is to collect changes, that is one. (2.0.0-rc1)

P.S. I'm struggling to piece together a code that works, there doesn't seem to be any sample. Currently I'm getting Sub claim is missing error.

I am having the same sub claim issue, mentioned here.

P.S. I'm struggling to piece together a code that works, there doesn't seem to be any sample. Currently I'm getting Sub claim is missing error.

Our sample host is the main working sample for now: https://github.com/IdentityServer/IdentityServer4/tree/dev/src

And if you need ASP.NET Identity: https://github.com/IdentityServer/IdentityServer4.AspNetIdentity/tree/dev/src

Version 2.0.0-rc1 works fine for me !

Versin 2.0.0-RC1 works for me except:

.AddConfigurationStore(builder => builder.UseSqlServer(conString, options => options.MigrationsAssembly(migrationsAssembly))) .AddOperationalStore(builder => builder.UseSqlServer(conString, options => options.MigrationsAssembly(migrationsAssembly)))

@shauliz

There were some changes to IdentityServer/IdentityServer4.EntityFramework. You can implement it similar to the example that you find here:

https://github.com/IdentityServer/IdentityServer4.EntityFramework/blob/bd1ba47635a980a77853826bb05d445cbde49f63/src/Host/Startup.cs#L36-L56

That one worked for me.

@StefanKert
Thanks!

@StefanKert Did you ever try and run this against an existing IS4 (.NET Core 1.1 database)?

It seems the additional fields in the Client model don't have a migration, so never make it into the db. Ensuring that it crashes when trying to access that table.

@StefanKert Did you ever try and run this against an existing IS4 (.NET Core 1.1 database)?

I can't imagine that will work. You need to migrate the DB, which is your responsibility.

@kieronlanning sorry for the delay. Like @brockallen mentioned you need to create the migrations with the ef tools and update your database. This is not really the responsibility of IdentityServer.

@StefanKert / @brockallen - sorry, I should have said.

I figured that out eventually!

While migrating to Http.Sys (from WebListener), looking at the updated docs there is only a single comment about Http.Sys.
At the end of the article, the "DisplayName" warning with the solution with IISOptions really only applies to Kestrel, since for Http.Sys there is no such equivalent, I had to change this code.

I saw your comment about Http.Sys, but please consider adding some hints in the Docs as that would probably help those trying to implement Http.Sys on their own.

PS: I changed the code to the following (which I think would work in any case - so maybe worth integrating it in the sample or at least in the Quickstart docs?)

var providers = schemes
    .Where(x => x.DisplayName != null 
                         || (AccountOptions.WindowsAuthenticationEnabled 
                             && x.Name.Equals(AccountOptions.WindowsAuthenticationSchemeName)))
    .Select(x => new ExternalProvider
    {
      DisplayName = x.DisplayName ?? x.Name,
      AuthenticationScheme = x.Name
    }).ToList();

Thanks

@dviry can you open a new issue or add to the previous issue we have for that? if you don't, then i worry we will lose track of your comments and research.

Just for information -

Also there is a breaking change in "ICustomAuthorizeRequestValidator" interface.
In version 1.5.2 the interface had method
Task ValidateAsync(ValidatedAuthorizeRequest request);

Now in version 2.0
Task ValidateAsync(CustomAuthorizeRequestValidationContext context);

If you have implemented your custom authorize request validation logic using this interface then you need to make some code changes.

Also If you have implemented your custom ClaimsService by implementing 'IClaimsService' or by overriding the 'DefaultClaimsService' class in Version 1.5.2 then while upgrading to 2.0 you will encounter compile error. You need to make some minor code adjustments to make it work in your custom implementation.

Again this is just for information.

@brockallen have we documented everything? can we close this?

@brockallen have we documented everything?

well, strictly speaking we can't ever say that. but as for the formal docs, i think we have done everything we intended to.

can we close this?

IMO, yes.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings