tags:

views:

67

answers:

2

One of my applications is a public website, the other is an intranet. The public website runs using a limited security user that must access a certain table through a view, whereas the intranet can access the table itself.

This seems like it would be quite simple to setup using Fluent NHibernate. In my ClassMap I could do a check like this:

public class MyEntityClassMap : ClassMap<MyEntity>
{
     public MyEntityClassMap()
     {
         if (NHibernateConfig.Current.Context == "intranet")
            Table("t_MyEntity");
         else
            Table("v_MyEntity_pub");
         ... etc
     }
}

Is there a simple way of doing this for embedded hbm files? The only method I can think of would be to have two copies of the hbm file, which would be confusing and far from ideal.

Is there perhaps a better way of achieving the same result?

A: 

Although this is perhaps not the most helpful answer to your problem, I don't believe that this is possible in a mapping file. I also don't think that two hbm files would work for the same name, as it would be unable to distinguish between the two, you would instead have to have two identical objects each with slightly different names and mapping files. Which as you said in your question, would be completely confusing and ideal would simply be a spot on the horizon that you were hoping to, someday, reach.

Why is it that can't access everything directly through the view? I'm assuming there is no writing involved in this process? Is there any way you can change this method of accessing data while still maintaining your security?

Jay
To answer your concerns: 1) I could put the two hbm files in seperate assemblies and then switch which assembly I am using for configuring NHibernate. 2) The view is used to restrict access to sensitive data (e.g. by restricting access to data older than 1 day). This is a common way of implementing such security. 3) It is possible to run inserts and updates on a view - sql will work out that they need to go to the table. 4) I can't think of a better way of implementing this security feature.
cbp
@cbp 1) I assumed because of your two different access types (Internet/Intranet) that security would change depending on the way it was accessed, not two different assemblies (which I see is in your question, my bad :)) 2) This kind of security doesn't absolutely need to be at the database level and instead can be application level. 3) I wasn't asking about writing because I believed that you can't write to views, it was because if all you need is simple data based rules you can filter easily in your mapping files with the 'where' attribute on collection access
Jay
4) If it were my application and I wasn't under strict guidance from the DBA, I would personally put in place my own security in the ORM itself, there are multiple ways to do this if you want me to explain in more detail. That being said I generally try to avoid creating views/SP's if possible and keep my business logic inside of the application when I'm using NHibernate. Though in some jobs people like having the separation of duties between DBA and developer, in the case of the developer having control over the database I believe this is not an issue. That's personal preference though :)
Jay
The thing is, if you have a public website then you have a certain exposure to IIS vulnerabilities, SQL injection etc. Sure you can do all you can to minimize this, but at the end of the day the you can never be 100% sure that there are no holes. Therefore if you have sensitive data stored in the same database that the public website is accessing, it is best to run the website's sql connection with a limited user account.
cbp
It is true that not many website developers do this, but they should!
cbp
To be honest, I don't believe that you can ever be 100% sure that there are no holes in your security, things such as SQL Injection should never be an issue in an ORM like NHibernate unless you're really opening yourself up to it as it's all parameterised. Saying that there could be vulnerabilities in IIS is just like saying there could be vulnerabilities in your database server which can allow people to gain direct access to your tables (this is about as likely as IIS allowing full table access in a well made system).
Jay
The extra level of security views allow are possibly a good idea in high security implementations, but are not a necessity for your general web application. If you start creating different views for different security levels and creating one off implementations of the site pointing to multiple versions of the same views, I believe there's probably a higher probability of developer error in the multiple builds you'll push out than your site actually being at risk of data being leaked through lack of view security.
Jay
+1  A: 

Actually what you ask it is possible. You can actually access the embedded XML files and alter their content before the SessionFactory is build (on Application Start).

Assuming your will choose to reference the "t_MyEntity" in your entities by default here is how you can dynamically change this reference when you want to reference the "v_MyEntity_pub" table instead (the code may not work as it is but you will get the idea):

    NHibernate.Cfg.Configuration cfg = new NHibernate.Cfg.Configuration();
    cfg.AddAssembly(ASSEMBLYNAME);

    if (NHibernateConfig.Current.Context != "intranet") //this is how you have stated you distinguish the intranet application from the other one.
    {
        string[] resourcesNames = assembly.GetManifestResourceNames();
        foreach (string resourceName in resourcesNames)
        {
            StreamReader sr = new  StreamReader(assembly.GetManifestResourceStream(resourceName));
            string resourceContent = sr.ReadToEnd();
            resourceContent = resourceContent.Replace("t_MyEntity", "v_MyEntity_pub");
            cfg.AddXmlString(resourceContent);
        }
     }

     ISessionFactory sessionFactory = cfg.BuildSessionFactory();

The above code should be executed only once for the lifetime of your application and only for the intranet application.

tolism7
Ah brilliant, this is what makes stackoverflow so awesome!
cbp