Did you re-upload all samples with OpenIddict 4.0 preview1 applied?
feededit opened this issue · comments
Confirm you've already contributed to this project or that you sponsor it
- I confirm I'm a sponsor or a contributor
Describe the solution you'd like
There seems to be some change.
Did you re-upload all samples with OpenIddict 4.0 preview1 applied?
Additional context
No response
Did you re-upload all samples with OpenIddict 4.0 preview1 applied?
Yes: as mentioned in the README, the dev branch was updated to target OpenIddict 4.0 preview2. The following changes have also been made:
-
The server samples no longer configure Identity to use JWT claims. While this was convenient, it didn't help folks understand how things worked in
AuthorizationControlleras theClaimsPrincipalinstance was generated by Identity under the hood. In the revamped samples, theClaimsPrincipalis created and populated manually, which is a more explicit model. -
The code flow client samples now use the OpenIddict client stack.
That said, samples for OpenIddict 3.x can still be found in the master branch: https://github.com/openiddict/openiddict-samples/tree/master
Hope it helped 😄
I'm a good user of openiddick, so I'm glad openiddick is getting better and better.
Thanks for the improvement.
I want to upgrade my site to OpenIddict 4.0 preview1.
Let me ask you a few questions.
- Do I need to modify both Velusia.Client and Velusia.Server?
Can I modify only Velusia.Server without modifying Velusia.Client ?
- Do I need to redo all settings for my current site? Or can only RuGet update?
openiddick
Haha, it's not the same project (that one is likely 18 yo+ 🤣)
Do I need to modify both Velusia.Client and Velusia.Server?
No. The changes that are strictly required when migrating to 4.0 are actually very limited: you only need to remove the AddClaim calls that specify a list of claim destinations as this overload no longer exists in 4.0. Instead, you can use the new principal.SetDestinations() extension that takes a delegate.
Can I modify only Velusia.Server without modifying Velusia.Client ?
Yes. The OpenIddict client will be the recommended option in 4.0 but you can of course keep using the MSFT OIDC handler if you're happy with it.
Do I need to redo all settings for my current site? Or can only RuGet update?
No. Preview1/preview2 don't require a schema change so updating the packages and changing the AddClaim calls if necessary is enough.
I prefer to replace everything with the new version.
But I will follow your answer.
My plan is this.
I will install a new ruget.
If any error messages appear, I will try to fix them.
If you think I'm right, please guide me on how to install Ruget.
I will select the authentication cookie of Velusia.Client as [ ASP.NET Core Identity] method.
To do that,
Callback() of Client.Controllers
I want to fix it as below.
using Microsoft.Extensions.Logging;
public class AuthenticationController : Controller
{
private readonly ILogger<AuthenticationController> _logger;
private readonly SignInManager<IdentityUser> _signInManager;
public AuthenticationController(SignInManager<IdentityUser> signInManager, ILogger<AuthenticationController> logger)
{
_signInManager = signInManager;
_logger = logger;
}
public async Task<ActionResult> Callback()
{
~~~
// await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(identity), properties);
var xresult = await _signInManager.SignInWithClaimsAsync(TUser user, bool isPersistent, IEnumerable<Claim> additionalClaims)
return Redirect(properties.RedirectUri);
}
}
Is it possible?
I will select the authentication cookie of Velusia.Client as [ ASP.NET Core Identity] method. Is it possible?
It's definitely possible. You can take a look at the OpenIddict.Sandbox.AspNetCore.Server project in the main repo: it includes an AuthenticationController using ASP.NET Core Identity. It's very similar to the one you have in Velusia.Client but it uses a different constant to use Identity's external cookie mechanism:
Your sample source is too difficult for me to understand.
You seem to have misunderstood my question.
I asked if I could use [signInManager.SignInWithClaimsAsync] instead of [HttpContext.SignInAsync].
await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(identity), properties);
var xresult = await _signInManager.SignInWithClaimsAsync(TUser user, bool isPersistent, IEnumerable additionalClaims)
( You used SignInAsync of [HttpContext] . but I want to use SignInWithClaimsAsync from [SignInManager] . )
Technically, you can, but SignInManager.SignInWithClaimsAsync() directly creates an "application cookie" (i.e the main cookie) and not an "external cookie" as shown in the sample I linked. It's not how the normal Identity flow works.
Can you tell me how?
I'll use one question to solve.
What are you trying to achieve exactly? As I said, it's a bad idea, so better be sure it's really the best approach 😄
I have the mindset that SSO requires sites and all subdomains to be logged in at once.
To enable [options.Cookie.Domain ].
The code below doesn't work.
services.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie(options =>
{
options.LoginPath = "/login";
options.LogoutPath = "/logout";
options.Cookie.Domain = ".site.com";
options.ExpireTimeSpan = TimeSpan.FromMinutes(50);
options.SlidingExpiration = false;
});
.AddCookie() is used to create a new instance of the cookies handler. If you use Identity in this application, you need to configure the existing cookies handlers registered for you by Identity using these extensions: https://github.com/dotnet/aspnetcore/blob/main/src/Identity/Core/src/IdentityServiceCollectionExtensions.cs#L104-L120
I see it for the first time.
Please explain..
Put the above code in setupAction and run [ services.Configure(setupAction);]?
You're indeed expected to use these extensions this way:
services.ConfigureApplicationCookie(options =>
{
options.LoginPath = "/login";
options.LogoutPath = "/logout";
options.Cookie.Domain = ".site.com";
options.ExpireTimeSpan = TimeSpan.FromMinutes(50);
options.SlidingExpiration = false;
});You can remove .AddCookie.
In Velusia.Server I applied it.
But it is not available in Velusia.Client.
My question is a Velusia.Client issue.
My question is a Velusia.Client issue.
Velusia.Client doesn't use ASP.NET Core Identity as it doesn't need a users database. It simply uses a local cookie to store the user identity retrieved from Velusia.Server.
I know.
All subdomains of Velusia.Server are logged in together.
I want to log in all subdomains of Velusia.Client as well.
I consider this issue to be an important upgrade item for the development of openiddick.
I want to log in all subdomains of Velusia.Client as well.
But why do you need ASP.NET Core Identity for that in your client apps? Can't you just use .AddCookie()?
But why do you need ASP.NET Core Identity for that in your client apps? Can't you just use .AddCookie()?
yes, That's the only reason.
You've been saying I'm going in the wrong direction. I'd love to hear why
Finally found what I was looking for.
With the code below, all sites and subdomains are log in at once.
using Microsoft.Extensions.Logging;
public class AuthenticationController : Controller
{
private readonly ILogger<AuthenticationController> _logger;
private readonly SignInManager<IdentityUser> _signInManager;
public AuthenticationController(SignInManager<IdentityUser> signInManager, ILogger<AuthenticationController> logger)
{
_signInManager = signInManager;
_logger = logger;
}
public async Task<ActionResult> Callback()
{
~~~
// await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(identity), properties);
var userClaims = result.Principal.Identity as System.Security.Claims.ClaimsIdentity;
var username = userClaims?.FindFirst("name")?.Value; ;
var user = new ApplicationUser() { UserName = username, Email = username };
await _signInManager.SignInAsync(user, isPersistent: false);
return Redirect(properties.RedirectUri);
}
}
yes, That's the only reason.
You've been saying I'm going in the wrong direction. I'd love to hear why
As I said, ASP.NET Core Identity is only useful if you want to have a users database in your client, which is an usual scenario.
That said, if things are working properly, that's all that matters 😄
according to your answer
There seems to be no problem.
thank you.