I'm currently writing a modular desktop app in c# .NET 4.5 using prism 5.0.
My application is composed of the "core" (or the host), and several modules.
Each of my modules are implementing the IModule interface provided by prism.
The core of my application provides an "API" to the modules so they can interact easily with the application/other modules. For example, the "API" allows a Module to publish or subscribe to events or to communicate with a BDD.
Here is my problem :
There is some sensitive information in the BDD and I don't know in advance which module will be running. I want to handle the possibility of a "malicious" module: I would like to add a layer of security to my host application. For example, I want to check if a Module has the rights to delete something in the BDD.
How could I do that? I already have the rights of each modules stored in a BDD, but how could I know which module is making the call to the API in a secure way?
Everything should be done dynamically since I don't know in advance which module will be running.
For now this is what came to my mind:
The call to the API should take an extra parameter: a Type. But a module can easily fake a type by doing typeof(someType)
The call to the API should take an extra parameter: a IModule: the calling Module would send himself (this) as a parameter so I could check for the type in the API. But once again the calling module can still fake it easily by getting some instance of another module via the provided UnityContainer or whatever.
Check for the type of the calling object via the StackFrame. This one could be the "safer" but it's really heavy and dirty in my opinion.
Is there any other way? I'm very new to c# and modular pattern, I'm sure I'm missing something.
EDIT: I will use the sboutzen's method to authentifcate my modules at the loading of the assemblies. If the module is a known module I'll give him a random generated key. Each time the module want to make a call to the API he will have to give the provided key so I can check his identity.
This is the safest thing I can think of.
You can use strong named modules.
See https://msdn.microsoft.com/en-us/library/xc31ft41%28v=vs.110%29.aspx. This way you can authenticate and authorize each module (assembly).
Related
I am trying to use in jBPM users from existing ASP .NET MVC Web Site.
As I understand from docs and this forum topics (first, second) best solution would be implementing of UserGroupInfoProducer that will call external service. But due lacking of experience with java I faced with several problems.
First approach: Create project with required implementation, deploy it and config jBMP to use it.
Problem was in implement interfaces that declared in another project, I've tried to add maven dependencies but after failing with some classes I've just added reference to required jar.
Deploy it on jboss like war failed, deploying like jar succeeded but server did not find UserGroupInfoProducer and other implemented interfaces.
Another problem in changing config of jbmp-console. Only way that I've found for that is modify archive directly, but I don't this it's right solution.
Second approach: Create own package of jBPM with required classes.
Problem here that I don't know what repository use for this and how to build version for my server.
As I understand from this link I need to use jbmp-console-ng, only maven task for creating war package that I found was in jbpm-console-ng-showcase I've tried to run it (release 6.2.0 Final) on:
On Windows: failed to execute because of maven error about long path, after migrating project to gradle and excluding dependencies on jmxtools-1.2.1.jar and jmxri-1.2.1.jar it created war but jboss failed to start service.
On Mac and Ubuntu using virtual box: it required to downgrade java to 1.6 and built war after this, but it failed to deploy due duplication of some classes.
As I understand you need to build diferently for each version of server but I don't know how to do this.
Third approach: Create come simulation of supported authorization ways. As I understand jBMP support LDAP, JAAS, database and file. Database and files will require duplicating users so I researched about simulating LDAP or JAAS (preferably using C#) but did not find any acceptable way.
I will be very grateful for any advise which of this approach may work or some other suggestions. Especially about building war of jbmp-console.
version used:
jBPM(6.2.0 Final), jBoss(Wildfly 8.1.0 Final), Java(1.8.0.73), Ant(1.9.6), Gradle(2.11), Intellij IDEA (15.0.3).
After a few weeks of try and error approach I have finally managed to provide fully custom authorization module for JBPM suite ( kid-wb, server and dashbuilder ) in our application. It wasn't easy and required some magic - overwriting two classes won't do it :)
My requirements was quite complex and final solution consist of kie-wb, server, dashbuiler and external authentication which provide by REST Web Service response users with roles based on token passed in session. Another thing that you have to keep in mind is that kie-wb and server are communicating through BASIC authentication - if you want to use server also you have to provide two possible methods of authentication. I won't be able to publish here any code, because it is not an open source project, but I will try to help the best I can.
If you are using WildFly as you are saying above, what you should look at is Undertow Servlet Extension
Overwriting handleDeployment method allow you to write your own IdentityManager( if you need one ) and register your custom AuthenticationMechanism.
To implement your own AuthenticationMechanism you should look at this project Custom Spnego Auth for WildFly
My solution was based on mentioned above project - you don't have to implement every class - in my case writing my own class implementing AuthenticationMechanism was sufficient to get custom authentication working in kie-wb ( not for server though).
So if you already have overwritten Servlet Extension ( and registered by putting file io.undertow.servlet.ServletExtension containing your custom servlet extension class name inside /WEB-INF/classes/META-INF/services/ path of .war file ) and implemented custom AuthenticationMechanism next thing you should do is write class implementing org.jboss.security.auth.spi.LoginModule interface. If you don't want to implement this interface all by yourself you can just extend one of already implemented classes from WildFly - for example UsernamePasswordLoginModule or other.
To let WildFly know that we are using non-standard Login module we have to modify standalone-full.xml as follows:
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="com.package.CustomAuth" flag="required">
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
and then...we are almost done :) One thing left to do is to modify deployment descriptor inside .war file. We have to change web.xml inside /WEB-INF dir as follows:
<login-config>
<auth-method>BASIC?silent=true,CUSTOM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login_failed.jsp</form-error-page>
</form-login-config>
</login-config>
CUSTOM is name of your authentication mechanism that was registered inside class implementing Servlet Extension class.
Above instruction does not cover kie-wb <-> kie server communication. This matter was more complex and required a few workarounds. As I said before I won't be able to provide full solution with more detailed examples, but feel free to ask me anything refering this case.
I started to create a log system based on Observable Pattern. For that I use Reactive Extensions.
I have an IObservable called ILogInfo and a IObserver called ILogObserver.
I have a main application with various modules that used shared libraries. Each module implements an observer of ILogInfo and the modules can work in parallel. My problem here, is that I would like to observe only the ILogInfo registered in the scope of my module.
In this scheme I have two modules (Module A and Module B), each module uses many libraries which push information via ILogInfo. When LibC push a new ILogInfo I would like that only the calling module catch (observe) the information. For example when the call comes from Module B, I don't the information to be observed by Module A. How could I do this ?
This isn't a question about Rx really. You need to be able to get calling context from the ILogInfo to route it appropriately.
You can provide either provide that context explicitly from the caller (the sender suggestion in the comments seems like a simple, workable suggestion of this) or do an expensive stackwalk to determine the calling module (which won't work in asynchronous situations) or otherwise you'll have to maintain the caller in ExecutionContext by setting data in the LogicalCallContext - this works in more asynchronous situations but is more complex.
I don't know about your specific situation, but given the need to isolate logging so throughly, I wonder if hosting multiple copies of the libraries in separate per-Module AppDomains might be easier, giving you complete isolation.
I hope there's a really good reason for this requirement, because it feels very complicated when existing logging frameworks have good solutions for providing context (like activity tracing in the logging application block and in WCF for example).
I agree with James here. This isn't really an Rx question.
I also have a question of how will you deal with logging where many modules reference the same library?
Is there a reason you are not considering a common Logging solution like Log4Net?
I have a Silverlight 4 library L which has a dependency that is to be provided at run-time via a plugin P.
I am using a DeploymentCatalog along the lines of the example provided by MEF documentation and all is well: the XAP of the plugin P is correctly downloaded asynchronously and the import is satisfied.
However, I cannot control the details on the Silverlight application A that will be using library L and I cannot exclude that A itself might want to use MEF: therefore it's possible that at some point A might issue a CompositionHost.SatisfyImports(...) CompositionHost.Initialize(catalog) call for its own purposes which I understand can only be invoked once.
Am I missing something here or partitioning the application across multiple XAPs can only be achieved if one has complete control of the Silverlight application and libraries?
Stefano
CompositionHost.SatisfyImports can be called many times. CompositionHost.Initialize can only be called once. As a library, it is not a good idea to call that method because the application may do so. Since you need to create and use a DeploymentCatalog, it's probably better if you don't use CompositionHost at all in your library, since you want to avoid calling the Initialize method, which would be the way to hook the CompositionHost to the DeploymentCatalog.
You can create your own CompositionContainer hooked up to the DeploymentCatalog and call GetExports or SatisfyImports on the container you created. CompositionHost is pretty much just a wrapper around a static CompositionContainer.
It's not usually a good idea to tie yourself to a single dependency injection container in a library, instead you'd usually want to abstract that away using something like the CommonServiceLocator, which leaves the choice of IoC container a preference of whoever is consuming your library.
I only started with MEF in Silverlight a month ago, so I'm definitely not an authority.
The first thing I noticed is that CompositionHost.SatisfyImports has been replaced with CompositionInitializer.SatisfyImports .
Second I could not find any reference to "SatisfyImports can only be invoked once"
My scenario is the following:
I have a BL xap which I use/link to from my application
The BL has some Imports that will be satisfied by calling SatisfyImports from the Application
The BL also has some imports that
cannot/will not be resolved until a
certain custom (third party)
module/xap will be loaded (loaded
when demand that is). When the custom
module becomes available (is loaded)
I solve the missing imports with an
extra call to
CompositionInitializer.SatisfyImports:
E.g:
If DomainSpecificModuleLogic Is Nothing Then
'this is required to trigger recomposition and resolve imports to the ThirdPartyModule
System.ComponentModel.Composition.CompositionInitializer.SatisfyImports(Me)
End If
So I have multiple calls to SatisfyImports (at different moments in time) and no problems due to this -> you do not required control over the whole application, just make sure that when someone accesses an object from your library that uses MEF, you have a call to SatisfyImports
Note: my BL is a singleton, so for sure I am calling SatisfyImports on the same object multiple times.
I have a modular application, it behaves quite like a plugin system. Module B is dependent on Module A. When B is present, then some dialogs (titles etc.) need to be altered in Module A. Also, a different entity should be used for a list when Module B is present, which I want to include in Module B, so A doesn't know about it during compile time. Creating an abstract base in A for the entity is something I want to avoid as well.
How would you implement this requirement? The modules can communicate in various ways:
1.) Microsoft Unity is used for Object creation and dependency injection
2.) The modules can communicate via a Message-System.
3.) There's an EventAggregator which all the modules can use
I don't want to sublcass the dialog in Module B and just alter the typemapping in unity, because then I'd have to provide the whole dialog in another module. Also, if some other module wants to make other changes to the dialog, it'd be impossible.
Suggestions welcome!
Without knowing specific details, I would use interfaces to blend the plug-in components/modules. Require that each plug-in component implement an interface -- say IPluginComponent or whatever makes sense. (Actually, only components that must communicate or interact would actually be required to implement the interface.) Once all modules are loaded, the host application can fire methods or events on the components.
Personally, I like to keep things data-driven and simple as much as possible; so I might favor a "two-phase" pass through the modules. This keeps the dependencies between modules simple. So in the first phase, when all components are loaded, the host application fires the "ContributeSharedData(Context ctx)" method, where each component sets any values in a shared context. (This might also be called "Init(ctx)".) The context might be as simple as a name-value-pair collection, e.g. Module B says *coll["ModuleB_Installed"] = true*, or it could add itself to a list of modules, or... the possibilities are endless. The context can be whatever class or structure is required to enable these components to work together.
The next pass -- if required -- would be for the components/modules to configure themselves based on the shared context. So the host might run through all the modules supporting the shared interface and fire the "Configure" method or event. Then ModuleA for instance can look in the context and see that ModuleB is installed, and configure its interface accordingly.
If an interface doesn't make sense for your situation, you can use any method of contributing shared data in a generic way to a common location, e.g. messaging or other common classes.
Hope this helps!
I need to create a project for multiple web services using WCF in c#. The web services will be calling other assemblies to perform the core processing. The assemblies will be accessing data from SQL Server. One of the parameters that will be part of every web service method will include the database to use. My problem is how to pass the database parameter to assemblies to use. I can't change all the signatures for all the satellite assemblies to use. I want to reference some kind of variable that the satellite assembles reference. Theses same satellite assemblies are used with a Windows Forms app and an ASP.NET app so I would need to have something that all types of applications could use. Static fields are not good since for one web service call the database could be "X" and for another it would be "Y". Any ideas?
This is the sort of thing that might play nicely with an IoC or DI framework - having some interface that includes the database information, and have it pushed into all the callers for you. Even without IoC, hiding the implementation in an interface sounds like a solid plan.
With your static concept; a [ThreadStatic] might work but is a little hacky (and you need to be religious about cleaning the data between callers), or another option is to squirrel some information away on the Principal, as this is relatively easily configured from both WCF (per-call) and winforms (typically per-process). In either case, be careful about any thread-switching (async, etc). In particular, note that ASP.NET can change threads in the middle of a single page pipeline.