If not, what are my options? I presume the OData Web API is the next easiest to implement option?
The error message:
Attempt by security transparent method 'Breeze.ContextProvider.BreezeConfig.get_Instance()' to access security critical method 'System.AppDomain.add_AssemblyLoad(System.AssemblyLoadEventHandler)' failed.
Assembly 'Breeze.ContextProvider, Version=1.5.0.0, Culture=neutral, PublicKeyToken=f6085f1a45e2ac59' is partially trusted, which causes the CLR to make it entirely security transparent regardless of any transparency annotations in the assembly itself. In order to access security critical code, this assembly must be fully trusted.
Breeze requires Full Trust if using the "Breeze Web API."
Related
I am currently developing in a standalone (Not .Net Core Hosted) Blazor WebAssembly app in .Net 5.0. I have been trying to convert a couple Asp.Net MVC WebAuthn examples over into my Blazor app for Passwordless Authentication.
The issue I am experiencing now is due to this app's architecture since it is not a Blazor Server app. The Asp.Net MVC example I am following has everything including the client hosted on the server whereas my app is split Web Client/ Web API architecture.
So far however, I have managed to get most of the way through these differences but now the issue I am having is in the last functionality of registering the credential with the server within the Make Credential request of the Fido2NetLib Library. on line:
// 2. Verify and make the credentials
var success = await _lib.MakeNewCredentialAsync(attestationResponse, options, callback);
I am receiving an error saying: "Origin https://localhost:44325 not equal to original origin https://localhost:44309". Now of course this is a dev environment but it will be exactly the same in production as the API and the client are hosted in two different domains.
Any ideas would be greatly appreciated. I am hoping I can "white list" certain domains?
WebAuthn defines the origin to be the fully qualified origin. Per referenced RFC6454, this is the tuple of scheme, host, and port. You can't go breaking the rules without deviating from the standard.
WebAuthn gels very well with using a separate identity provider (e.g. something Open ID Connect/IdentityServer4-based) as the origin that deals with credentials will always be the same regardless of the relying parties involved.
I am trying to get a SAML 2.0 token from an ADFS 2.0 ws-trust service using C#. The popular sample is this one http://leastprivilege.com/2012/11/16/wcf-and-identity-in-net-4-5-external-authentication-with-ws-trust/. However, this sample uses a UserNameWSTrustBinding which, according to this article http://msdn.microsoft.com/en-us/library/jj157091.aspx, did not make the jump to the System.IdentityModel namespace for 4.5.
I have been experimenting with this sample and some variants that I have found, but so far, the only results that I can get are a variety of error messages. I am wondering if there is any good way to debug the latest one, "The request for security token has invalid or malformed elements.". I turned on WCF logging on and determined that this message is being returned as a fault by the ADFS service.
Reviewing the AD FS 2.0/Admin events on the ADFS server, there is no indication of an error. Several posts indicate that this is common in an ADFS farm environment, but mine is a simple single server configuration.
Does anyone have a good way to diagnose this? Or, is there a good sample that comes with any configuration requirements on the ADFS server side?
This link http://social.msdn.microsoft.com/Forums/en/Geneva/thread/33fc091b-505c-481c-a61c-a8541a5ccf23 shows how to enable WCF and WIF tracing for the server side of ADFS 2.0. Modify the config file at C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config. (Change the three switchValue settings to Verbose and modify the trace listeners.) While following the instructions, make sure to change the types on the listeners. Something like
<add name="ADFSWifListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\adfs1.svclog" />
I also had to grant "Everyone" full access to the C:\Logs folder, you can refine those permissions with auditing if you like. Once the .svclog files have been created, they can be viewed with SvcTraceViewer.exe in %ProgramFiles%/Microsoft SDKs/Windows/v8.0A/bin/NETFX 4.0 Tools (or any other SDK version probably).
NOTE: Microsoft will not support the notion of logging trace data directly to a file, so you will want to turn this off or configure according to this article http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(WS.10).aspx for a production deployment.
I'm trying to develop an authentication plugin for an ASP.NET MVC3 application that would use WIF for authentication. Since it's a plugin with an in-system configuration, I avoid touching the web.config file of the app or anything else. I've got it working, but now I'm trying to specify what claims the STS should send my app, and it seems that FederationMetadata.xml is involved, but I cannot find confirmation of that. In fact, I cannot find any information on this enigmatic file at all. What is it?
FederationMetadata tells potential relying parties what information the STS provides.
Your claims should be detailed in the EntityDescriptor/RoleDescriptor/fed:ClaimTypesOffered section
See http://blogs.msdn.com/b/card/archive/2010/06/25/using-federation-metadata-to-establish-a-relying-party-trust-in-ad-fs-2-0.aspx
FederationMetadata is a 2 way exchange. It is used to tell the Identity Provider WHAT claims you require and the Identity Provider can use the metadata to tell your application WHAT claims it offers by default.
This way you can ensure your application has all the claims support it requires when integrating with differing identity providers.
I'm currently working on a project running on JBoss AS 7 that requires authentication from a variety of sources. I'm trying to get an understanding of the various components that combine to provide authentication.
I have some assumptions / guesses as to how this all fits together, but I need to make sure that my understanding is correct. So below is what I understand to be the authentication process for JBoss AS7.
You have a security realm that defines how users are authenticated. This realm is then exposed to your application in order to secure some or all of it. In AS7 this is configured in the <subsystem xmlns="urn:jboss:domain:security:1.0"> element.
The realm can be configured to authenticate users against a variety of sources using login-modules, such as a database, LDAP, a local file or something else. Multiple login-modules can be defined, and you can specify some combination of login-modules must "succeed" in order for authentication to occur.
The actual username and passwords are passed in via a mechanism defined in the web.xml file (for servlets), defined in the <login-config> element.
Assuming that the above process is correct (and it may not be):
Does this whole authentication process fall under a specification like JAAS, or is JAAS just a small or optional part of this procedure?
Do all types of <auth-methods>'s (i.e. BASIC, DIGEST and FORM) work with all kinds of login-modules? This page would seem to suggest not, but I haven't seen any clear documentation matching <login-module> options <login-config> options.
The username and password flow from a login-config to a login-module seems straight forward enough, but what happens with systems like OpenID or OAuth where there are intermediary steps (like redirection to external login pages)?
How do projects like Seam 3 Security, Apache Shiro and Spring Security fit into this picture?
JavaEE security specification leaves a lot of space to container implementors so I will focus on JBoss implementation to answer.
JBoss security implementation
JBoss relies on JAAS authentication to implement JavaEE security. That way it takes benefits from a stable API and can use existing LoginModule implementations. Login modules are used to authenticate a subject but also to add roles to Subject. JAAS provides mechanisms for authorization, permission checking and JBoss uses it internally.
JAAS LoginModule does not only supports password-based authentication but also token-based authentication.
Token based authentications
A good example of what can be done in JBoss thanks to JAAS is the HTTP Negotiation support for Kerberos SPNEGO: an additional auth-method named SPNEGO is implemented thanks to a Tomcat Authenticator and token validation uses JavaSE standard Kerberos LoginModule.
By the way, the LoginModule API is not a requirement, it may even be too complex for some protocols. For instance, the implementation to support OpenID with PicketLink only uses Servlet API.
Third party security libraries
These libraries often provide security layers to an application running a JavaEE or pure Java context, even if it does not take benefits from JavaEE specifications for authentication or role-based authorization.
Spring Security provides other abstractions than JavaEE security for applications developers to implement authentication and authorization, mainly thanks to ServletFilter when a web application is concerned. A large panel of choices is available to secure his application: it is possible to mix multiple options like: JAAS usage, JavaEE container security usage or Spring Security specific implementations (the case of OpenID and OAuth). There is no dependency to JavaEE either so it may be use almost in any situation when running on JavaSE. Most architect choose to build application security on Spring Security to have the liberty to switch specific implementations in the future.
Apache Shiro is really similar to Spring Security but it is younger and probably easier to set up.
Seam security does not rely on JavaEE security or JBoss but only on Servlet and JSF APIs. It is obviously the easiest option for JSF/Seam-based web application. Behind the scene, it uses PicketLink implementations.
As a conclusion, the question to use third party libraries in addition or in replacement to JavaEE security depends on architectural choices: application complexity, vendor independence and portability, control on implementations for bug fixes or improvements. In your specific context, having multiple authentication sources requires a flexible solution like Spring Security which supports authentication provider chaining (or Shiro).
I would like to run exes and Windows Services in Medium Trust, but all the literature I can find suggests using
<system.web>
<trust level="Medium"/>
</system.web>
for ASP.NET, so I have tried that but using code from How do you check if you are running in Medium Trust environment in .NET? it still appears to have full trust. What is the correct way to do this?
The available approaches depend on the .NET version. Prior to .NET 4.0, the CLR enforced CAS policy, which made it possible to restrict permissions for any assembly. However, as of .NET 4.0, the CLR no longer applied CAS policy unless you enable it via the NetFx40_LegacySecurityPolicy element in any given application's app.config file. While this approach is currently available, you might want to keep in mind that it might not be supported in future .NET Framework versions.
The new style of permission limitation is via restriction of permissions by a host other than the "naked" CLR. This is what ASP.NET does, and it's what your alternate hosting platform would need to do as well in order to implement this properly. The simplest mechanism for such permission limitations is via a sandboxed appdomain. I am unfamiliar with Topshelf, and their intro docs don't make it clear whether they support this. However, it would presumably be a relatively simple enhancement, so it might be worth requesting the feature.