12 Replies - 2204 Views - Last Post: 12 September 2016 - 10:26 PM Rate Topic: -----

#1 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Identity in Data Access Layer?

Posted 12 September 2016 - 02:42 PM

Hey everyone, I implemented ASP.NET Identity with Owin on a MVC and had to create a connection string to my database in order to do a login/registration of a user.

However, the problem that I am coming across is that I wouldn't want the client to have that much access to something if they ever wanted to do something "bad."

So I was asking around and I was told to use Owin on the MVC and API I have created and use Identity on the Data Access Level so that everything goes through the pipeline and then back up to Authenticate and Verify.

However, all the research I'm doing is always showing me how to do the login/registration through the MVC only or through ASP.Net for web forms and they both require a connection string on that layer.

Would anyone have an idea on how I can implement Identity on my SOAP service and map it to the Logic layer through the API to the MVC? Or is that not possible?

Is This A Good Question/Topic? 0
  • +

Replies To: Identity in Data Access Layer?

#2 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 7107
  • View blog
  • Posts: 24,133
  • Joined: 05-May 12

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 06:23 PM

Nobody said that you need to use the same database for authrntication as for your processing. Additionally, ASP.NET MVC has other membership options like LDAP, OAuth, etc., because of its extensibility model.

Furthermore, step back and look more closely at ASP.NET's security model and the way MVC integrates with it. You can potentially mark everything as requiring authentication -- in fact Web AP 2.0 takes the whitelist approach, as opposed to the MVC blacklist approach.
Was This Post Helpful? 0
  • +
  • -

#3 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 06:34 PM

I don't quite follow. What I am trying to do is create a pipeline from the database using the Entity Framework where the information will be transferred as Data Access Objects using a mapper(I am using AutoMapper)

I have done XUnit Tests on it to make sure that I can Read, Write, Update, and Delete to and from the database. After that, I used WCF for my SOAP service where the API I have will reference that. The MVC will then be using the API to be able to get the information going down that pipeline.

For Authentication purposes on the Client Side, I have to make a registration of users and a login for users and have roles implemented for them.

I was able to do that using Owin and Microsoft ASP.NET.Identity and other packages that go with those. The issue I am having is that I used an ASP Web Form to make the login/registration and put the connection string to the database in the Web.Config File.

The issue with that is that it's very vulnerable. So I was told that using Identity in the Data Access Layer would be better, but I am having a hard time finding resources online that will help me have an understanding on how I should implement it. I was also told that the Client side will be using Owin to use cookies for Authentication purposes since the Data Layer will pass it back up to the API and so forth.

I never worked with authentication and authorization in this process before, so I am playing around and asking around to further enhance my understanding of it as I am pretty unsure of how to start this.
Was This Post Helpful? 0
  • +
  • -

#4 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 7107
  • View blog
  • Posts: 24,133
  • Joined: 05-May 12

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 07:39 PM

The database used by your ASP.NET.Identity does not have to be the same database used by your wed service. You can have more than one connection string in the web.config. Let your authentication and authorization code use one connection string, and the actual web service use another.

Out of curiosity, what is considered "very vulnerable" about having the the connection string for the database in the web.config? This is a Microsoft recommended configuration. Unless you screw up your IIS directory permissions, a user can see the contents of your web.config. Unless you screw up your code server side code and execute user provided code, a user cannot generate input to execute code to dump the contents of your web.config. Unless you screw up uploading and saving files, a user cannot upload a page that dumps your web.config.
Was This Post Helpful? 0
  • +
  • -

#5 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 07:52 PM

But having the connection string in the Web.Config on the Client Side? Wouldn't it be better if it were in the Web.Config on the Soap Service?

And I haven't thought about having a separate Database for the authentication.
Was This Post Helpful? 0
  • +
  • -

#6 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 7107
  • View blog
  • Posts: 24,133
  • Joined: 05-May 12

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 08:06 PM

Client side? The web.config lives on the web server.
Was This Post Helpful? 0
  • +
  • -

#7 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 08:09 PM

The web.config is in the solution of my client. Isn't that pretty much exposing things you wouldn't want a user to have access to by any chance? And if it does live on the web server, wouldn't the user be able to access some of the web config by any chance?
Was This Post Helpful? 0
  • +
  • -

#8 Curtis Rutland   User is offline

  • (╯□)╯︵ (~ .o.)~
  • member icon


Reputation: 5106
  • View blog
  • Posts: 9,283
  • Joined: 08-June 10

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 09:28 PM

I think you have a few things confused. Web.config belongs to ASP.NET projects, which must be hosted. The servers are configured by default not to serve that particular file, so there is no chance (unless you explicitly allow it, which nobody does) of the web.config file being served to actual end users. It's perfectly good practice to put connection strings in the Web.Config; that's why there's a configuration element for it.

Also, are you writing a SOAP (WCF) service that your ASP.NET website uses? Why not just use the service code directly in your web application? Separation of concerns doesn't necessarily mean adding another transport layer to your application; if you're abstracting the application logic, you can do that just as well to a DLL.
Was This Post Helpful? 0
  • +
  • -

#9 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 09:47 PM

@Curtis

My project is being split up into 3 solutions with multiple projects per solution.

The first solution is the Data Access which uses Entity Framework and also has another project inside the solution that uses WCF for my SOAP service. I used XUnit to test if both the Entity Framework and the SOAP service could do Read/Write/Update/Delete.

After that, I created another solution for the business logic. The business logic solution was split into 3 projects: The API(used a service reference from the SOAP service), the business logic that had the mapper and the helper class to get the information from the previous solution, and the Unit Test.

Once the API was able to reference the SOAP service and everything checked out okay, I moved onto the Client solution which has the UI for the user and uses the API that I had created from the Logic Layer.

The only layer that has the connection string is the Data Access while everything else has a service reference to the SOAP service in the Logic Layer for the API and then the Client Layer uses the API.


It's a lot of abstraction, but those were the specifications that were wanted.

So aside from all of that, you think I can alleviate some of the complexity by putting all of that into a DLL or another connection?
Was This Post Helpful? 0
  • +
  • -

#10 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 7107
  • View blog
  • Posts: 24,133
  • Joined: 05-May 12

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 10:08 PM

Did the specification require 3 solutions? Or did it require that each of the layers have to live on a separate web application/service?

Most specifications I've encountered describe what the operations a system should be able to support, but leave the actual architecture up to the developer. It's odd that it would even require that you have 3 solutions. What if you wrote everything using notepad and used MSBuild or NAnt for your builds -- no solution files anywhere in the picture.
Was This Post Helpful? 0
  • +
  • -

#11 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 10:14 PM

@Skydiver

Yes, they wanted the entire app to be created using Visual Studio. We have 3 teams working on different parts of the application. Each team has to have 3 solutions. There will be a total of 9 solutions or more as of right now. They say the reasoning for this is because they want everything to be component based/modular.

And each of these different parts of the project will be put together. It's very complex for me to understand the grand scheme of things.
So I've been trying to see a pattern with all of this.
Was This Post Helpful? 0
  • +
  • -

#12 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 7107
  • View blog
  • Posts: 24,133
  • Joined: 05-May 12

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 10:15 PM

Anyway, if your client layer only ever talks to the business logic layer, why would it even have connection strings for the database behind the SOAP service? If all the authentication and authorization is done in your client layer, then it can use its own database. It need not use that same database behind the SOAP service. If the thought is that authentication and authorization in the client actually just calls the business logic layer, and that layer would in turn do lookups by making SOAP calls to the web service layer, there is still nothing that requires the same database used for authentication and authorization use the same database used by rest of the data access layer.
Was This Post Helpful? 0
  • +
  • -

#13 fearfulsc2   User is offline

  • D.I.C Regular

Reputation: 16
  • View blog
  • Posts: 279
  • Joined: 25-May 16

Re: Identity in Data Access Layer?

Posted 12 September 2016 - 10:26 PM

That makes a lot of sense and I'm probably going to end up doing that. So even if my Database has information of people on there and those people will in turn have a username/password, a separate database(for authorization/authentication) would be fine to do so?

And the data layer is the only layer with the connection. The SOAP service uses a mapper to get the Data Access Objects(DAOs) and that is where the pipeline up the layers begins.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1