runtime: Some System.Security.Principal types are missing members present in Desktop
The following members are on types implemented in .NET Core. However on desktop in 4.5+ they have more members. The members below are missing from Core.
The problem with this situation is
- it defies user expectations that if a type X exists, code from other platforms that use X will work on .NET Core: instead they have to reason about individual members on X
- in some cases it cannot be fixed without servicing – for instance methods we could supply a package with extension methods, but it would not be binary-compatible as different type identity
I didn’t look at usage data. Any that are not be technically possible on Core in ideally would exist but throw PlatformNotSupportedException. Even if we don’t have time to implement them, it’s potentially valuable to do that (allows compile to succeed, for a runtime path that may not be followed).
This is not a NS2.0 issue. The types are not in NS2.0
MembersMustExist : Member 'System.Security.Principal.IdentityReferenceCollection.IsReadOnly.get()' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity..ctor(System.IntPtr, System.String, System.Security.Principal.WindowsAccountType)' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity..ctor(System.IntPtr, System.String, System.Security.Principal.WindowsAccountType, System.Boolean)' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity..ctor(System.Security.Principal.WindowsIdentity)' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity..ctor(System.String, System.String)' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity.DeviceClaims.get()' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity.Impersonate()' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity.Impersonate(System.IntPtr)' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsIdentity.UserClaims.get()' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsPrincipal.DeviceClaims.get()' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.Principal.WindowsPrincipal.UserClaims.get()' does not exist in the implementation but it does exist in the contract.
also
MembersMustExist : Member 'System.Security.SecurityContext.SuppressFlow()' does not exist in the implementation but it does exist in the contract.
MembersMustExist : Member 'System.Security.SecurityContext.SuppressFlowWindowsIdentity()' does not exist in the implementation but it does exist in the contract
For completeness, these relevant types are missing:
TypesMustExist : Type 'System.Security.Principal.WindowsAccountType' does not exist in the implementation but it does exist in the contract.
TypesMustExist : Type 'System.Security.Principal.WindowsImpersonationContext' does not exist in the implementation but it does exist in the contract.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 65 (64 by maintainers)
To update from an internal discussion we will not bring back .Impersonate due to security concerns about it’s function and the api design. Instead RunImpersonatedAsync will be implemented and the RunImpersonated APIs will be the only impersonation APIs we support.
@terrajobst will dig out the results of the API gap meetings we had where we ruled out APIs for security reasons and update the missing API issue to flag the ones that are not returning.
@MarcoRossignoli I apologise for discarding the work you put into this. It was entirely our process failure here, and nothing to do with your code.
I can’t say it enough, thanks for the great work you are doing!
Ditto, thanks again @MarcoRossignoli
You can delete them here. These attributes should be only on types that really have to do something with COM Interop.
I agree with fixing this, but I am not sure whether WindowsImpersonationContext is the right way to fix that. WindowsImpersonationContext feels pretty heavy weight compare to what the current .NET Core implementation does. It may regress something important - you should measure.
The netfx execution context was a fixed hard-coded set: https://referencesource.microsoft.com/#mscorlib/system/threading/executioncontext.cs,493. It included WindowsIdentity as part of SecurityContext.
The fixed hard-coded set was both too much (your app paid to flow things it did not care about or ever used) and too little (your app could not extend the set of things to flow).
AsyncLocals were invented to make this abstract. The execution context in core is a collection ofAsyncLocals.Yes, more smaller self-contained PRs is better.
@MarcoRossignoli we’re not going to set up a domain just for that purpose - I would just copy the code - if you have a domain locally you could try - otherwise we can open an issue for one of us to try it locally.
No need to apologize, you have a day job 😄 Let me see who I can find here.
@ViktorHofer yes, it’s in use by eg., some popular control vendors.
This would be for preview 2 at this point. But, many of the vendors we are working with will be trying “live” builds so relatively soon would be good.
From talking to @jkotas – we should not concern ourselves with the exception filter issue, we should just go ahead and port this. Need to find a dev.