Repository navigation
Conversation
|
|
||
| namespace Microsoft.AspNetCore.Authentication | ||
| { | ||
| public interface ISecureDataFormat<TData> |
There was a problem hiding this comment.
The Data interfaces are kinda specific to our Security repo implementations, these could live inside of the Security auth package instead... Thoughts @Tratcher ?
There was a problem hiding this comment.
It's only used on Options types, right? Then it's fine to move to the concrete package.
There was a problem hiding this comment.
👍 for moving the "data handling" back to the security repo 😄
|
They won't work anymore right? Then yes, start Obsoleting them. |
| /// </summary> | ||
| /// <param name="app">The <see cref="IApplicationBuilder"/> to add the middleware to.</param> | ||
| /// <returns>A reference to this instance after the operation has completed.</returns> | ||
| public static IApplicationBuilder UseAuthentication(this IApplicationBuilder app) |
There was a problem hiding this comment.
Why did Auth.Core have to move to HttpAbstractions?
There was a problem hiding this comment.
Do we want to be able to test auth without the security infrastructure, i.e. IISIntegration would like to add auth but not depend on Security
There was a problem hiding this comment.
So I moved the 'Core' pieces that are needed for the auth infrastructure service here. But the scheme specific helpers and base classes are still in Security.
So you can add schemes, and call into auth via what's in HttpAbstractions, but all the sugar around implementing an auth middleware lives in the Security PR (still to be recreated)
|
Now that an important part of the new security stuff is back in this repo, is there a particular reason the authentication methods ( |
|
@PinpointTownes extensions on HttpContext aren't sufficient? |
|
Altho there is a bit of wierdness in the new stuff that I don't like today, that you have to call AddAuthenticationCore for context.Authenticate to not blow up... |
They are. I'm just wondering if there's a technical reason for opting for extensions in this case 😄 |
|
@PinpointTownes did you have an alternative in mind? We expect this to be mostly called by infrastructure/framework code like Security repo stuff/Identity/Authorize code. |
|
I went with extensions mostly to keep roughly the same shape as the old context.Authentication.Authenticate look and feel. As it made updating the existing usages very easy in a Find/Replace. |
I suppose you could keep the existing It would have a pro: you wouldn't have to deprecate the existing abstractions. |
|
We can't touch the existing old interfaces as that's the interop story for the old 1.X packages still continuing to work in a new MVC. They will still work since they are using the existing unchanged IAuthenticationHandler and the old packages are still running the old code |
Plus MVC, since it relies on these methods for |
|
Yeah...so basically the main consumer of the new APIs is myself :) |
Hum my bad, I thought these things were supposed to be removed in 2.0. It's a bit strange tho'... as there's no guarantee that code written for 1.0 will still compile with 2.0 (that's even the opposite, otherwise you wouldn't increase the major version, right?) |
|
Yeah so clearly 1.0 code won't compile, but 1.0 packages should still work/run in a 2.0 app as there's binary compat. Hence we can't really touch the HttpAbstractions auth behavior if we want those to still work... They can continue to party there like its 2016 |
Really? So how do you explain things like openiddict/openiddict-core#359 (code written for EF Core 1.0 no longer works with 1.2/2.0 due to a signature change) or aspnet/SignalR#155 ? |
|
So, my guess is the reality will be more complicated yes :) |
|
Obsoleted old Auth APIs |
|
@davidfowl How do things look here? I'd like to start getting the additive changes in this week (Auth.Abstractions + Auth.Core). There's still one change that I'm not sure about, which is that Auth is now an optional service. A call to We could have hosting call AddAuthenticationCore similar to AddOptions, otherwise this is something that needs to be called during ConfigureServices, see aspnet/HttpSysServer@c57b98b#diff-2d7f0bf656ca8cab31fc9edcd837ee98R62 |
| public static Task SignInAsync(this HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties) => | ||
| context.RequestServices.GetRequiredService<IAuthenticationService>().SignInAsync(context, scheme, principal, properties); | ||
|
|
||
|
|
| /// <summary> | ||
| /// Returns the schemes in the order they were added (important for request handling priority) | ||
| /// </summary> | ||
| public IEnumerable<AuthenticationSchemeBuilder> Schemes |
|
|
||
| namespace Microsoft.AspNetCore.Http.Features.Authentication | ||
| { | ||
| [Obsolete("See https://go.microsoft.com/fwlink/?linkid=845470")] |
There was a problem hiding this comment.
I thought you weren't going to check these Obsolete's in until after you got all of the other repos converted?
There was a problem hiding this comment.
When I smush all the changes together for the merge, I won't check in anything outside of the 2 new assemblies, so you don't need to review anything outside of the Authentication packages in this PR
|
I think it's OK for AuthenticateAsync to not work until you add an auth middleware / services. We just need to make sure the caller (the AuthZ filter) gives you a good error message. |
| /// </summary> | ||
| public AuthenticationTicket Ticket { get; private set; } | ||
|
|
||
| // REVIEW: should we also remember AuthenticationScheme? |
There was a problem hiding this comment.
AuthenticationScheme will be in the AuthenticationTicket for success, and doesn't matter much otherwise. The caller already knows the scheme.
| } | ||
| } | ||
|
|
||
| public IDictionary<string, AuthenticationSchemeBuilder> SchemeMap { get; } = new Dictionary<string, AuthenticationSchemeBuilder>(); // case sensitive? |
| SchemeMap[name] = builder; | ||
| } | ||
|
|
||
| public void ConfigureScheme(string name, Action<AuthenticationSchemeBuilder> configureBuilder) |
There was a problem hiding this comment.
Where is ConfigureScheme used? I couldn't find it in this PR or Security. What's the scenario? Otherwise it seems redundant with AddScheme.
There was a problem hiding this comment.
Yeah we don't need this anymore, it was needed before we had named options, as it was used to configure the options that lived in the scheme.settings. Good catch I'll remove this
| /// <param name="principal">the <see cref="ClaimsPrincipal"/> that represents the authenticated user.</param> | ||
| /// <param name="properties">additional properties that can be consumed by the user or runtime.</param> | ||
| /// <param name="authenticationScheme">the authentication middleware that was responsible for this ticket.</param> | ||
| public AuthenticationTicket(ClaimsPrincipal principal, AuthenticationProperties properties, string authenticationScheme) |
There was a problem hiding this comment.
We're inconsistent about the type of things called authentication scheme. In some places it's a AuthenticationScheme, and in others it's just a string. Should the strings be called authenticationSchemeName? DefaultAuthenticationSchemeName? Or is that just overkill?
There was a problem hiding this comment.
Well we called it authenticationScheme historically, so I think that should be familiar enough, do you think its confusing currently? I think the type is enough to differentiate...
| { | ||
| public interface IAuthenticationSchemeProvider | ||
| { | ||
| Task<IEnumerable<AuthenticationScheme>> GetAllSchemesAsync(); |
There was a problem hiding this comment.
Yeah, I'll fill in the comments today
|
|
||
| <PropertyGroup> | ||
| <Description>ASP.NET Core common types used by the various authentication middleware components.</Description> | ||
| <VersionPrefix>1.2.0</VersionPrefix> |
| <PropertyGroup> | ||
| <Description>ASP.NET Core common types used by the various authentication middleware components.</Description> | ||
| <VersionPrefix>1.2.0</VersionPrefix> | ||
| <TargetFrameworks>net451;netstandard1.3</TargetFrameworks> |
|
|
||
| namespace Microsoft.AspNetCore.Authentication | ||
| { | ||
| public class AuthenticationMiddlewareTests |
There was a problem hiding this comment.
AuthenticationMiddleware moved back to Security
|
|
||
| namespace Microsoft.AspNetCore.Authentication | ||
| { | ||
| public static class TestExtensions |
|
|
||
| } | ||
|
|
||
| //public class TestAuthHandler : IAuthenticationHandler |
|
Updated all doc comments, removed Forbid from IAuthenticationService, and addressed PR feedback, I think I got them all, but @Tratcher you should double check the important ones, since I fixed some that you noted in the Security PR. |
| } | ||
|
|
||
| /// <summary> | ||
| /// Used by as the default scheme by <see cref="IAuthenticationService.AuthenticateAsync(Http.HttpContext, string)"/>. |
There was a problem hiding this comment.
Feels a little bit weird to add usings for doc comments, but whatever :)
| namespace Microsoft.AspNetCore.Authentication | ||
| { | ||
| /// <summary> | ||
| /// AuthenticationSchemes are basically a name for a specific <see cref="IAuthenticationHandler"/> |
| @@ -28,7 +37,14 @@ public AuthenticationScheme(string name, Type handlerType) | |||
| } | |||
|
|
|||
| // TODO: add display name? | |||
There was a problem hiding this comment.
Time to remove TODOs and file followup bugs?
There was a problem hiding this comment.
Yeah this one is already tracked so I can just remove
| throw new ArgumentException(nameof(authenticationScheme)); | ||
| } | ||
|
|
||
| var handler = await Handlers.GetHandlerAsync(httpContext, authenticationScheme); |
There was a problem hiding this comment.
If you're just using forms, social, or WsFed then there's one thing to sign in and out of (cookies).
If you're using Identity then there are several signouts and the app signs out of them all.
If you're using OIDC there are two signouts, and the app needs to choose which.
And if you're using Bearer then signout doesn't work anyways.
So having a default sign out scheme, or even defaulting to the sign in scheme would only help the first scenario which is less common. Forget I asked.
| <ProjectReference Include="..\Microsoft.AspNetCore.Authentication.Abstractions\Microsoft.AspNetCore.Authentication.Abstractions.csproj" /> | ||
| <ProjectReference Include="..\Microsoft.AspNetCore.Http\Microsoft.AspNetCore.Http.csproj" /> | ||
| <ProjectReference Include="..\Microsoft.AspNetCore.Http.Extensions\Microsoft.AspNetCore.Http.Extensions.csproj" /> | ||
| <PackageReference Include="Microsoft.Extensions.TaskCache.Sources" Version="1.2.0-*" PrivateAssets="All" /> |
| </PropertyGroup> | ||
| <ItemGroup> | ||
| <ProjectReference Include="..\..\src\Microsoft.AspNetCore.Authentication.Core\Microsoft.AspNetCore.Authentication.Core.csproj" /> | ||
| <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0-*" /> |
|
Good enough for initial merge @Tratcher ? |
|
Merged 13925be the new packages, will open a new PR with obsolete's which will be checked in at the same time we switch all of security over (RIP build) |
|
Obsolete PR #806 |
@Tratcher @davidfowl @ajcvickers
Should I start to obsolete the old Http.Authentication at the same time?
Part of aspnet/Security#1151