I have a WCF service set up on the web server. This service, when accessed, does some database operations. What sort of account (roles and permissions) should this WCF service have to interact with the data base and how the same can be created. Is network service the way to achieve this?
This service will be accessed by vast group of users and these users will be having varying levels of restriction. How should i go about implementing this in a most secure and robust manner??
Thanks in advance.
Well, this depends on many factors.
You have to first answer at least those two questions:
who is responsible of authentication: your active directory (user valid against AD), the database (SQL Server user), or do you use a custom authentication system (User table in your DB)?
who is responsible of authorization: your active directory (user group), the database (SQL Server roles), or do you use a custom authentication system (Role, UserRole tables)?
When you answer those questions, that are related to the way you want to manage security (not how to actually implement this with WCF), then you can find a way using WCF.
More specifically, you'll have to choose the WCF security configuration for authentication:
Message vs Transport security
Windows (great to integrate your application in an AD)
Username (login + password)
...etc.
Then a role-based authorization provider, if any:
SqlRoleProvider (SQL Server roles)
Windows groups (for Windows domains)
custom
etc.
So you have to make some choices first, then I recommend you to read this MSDN article to choose the security configuration to use, depending on how you expect managing authentication and authorization.
Related
We have developed a product which is a web application. While configuring it in IIS, we disable all the authentication modes except Windows authentication (app works on Windows authentication only).
We create a service account and provide admin access to that account on all the servers, and on database servers.
We configure the connection string in web.config with username and password of that service account. Everything was working fine till now.
We received a new requirement which says, no service account will be created and individual users will be granted database access. We have to configure our application in such a way that Windows credentials are used to access the app gets passed to SQL Server. Reason for this change: we can log the user accessing the database.
I set Integrated Security=SSPI in the connection string and tried with different App Pool Identity but to no avail.
We are even ready to change the code if same is required to achieve the functionality.
Can someone please help me what am I missing, or how it can be achieved? Please let me know if more information is required and I will be happy to provide the same.
App server and database server are on the same domain and network but different machines. Users accessing the application will be on the same domain and network. This is a intranet based application.
You need to enable and configure constrained delegation. Follow this document: How to Implement Kerberos Constrained Delegation with SQL Server. Your app pool need to be configured to impersonate, see Using IIS Authentication with ASP.NET Impersonation.
Also this will be a hop scenario so you will have to enable delegation for the IIS server and if you intend to pass user credentials then you need to enable delegation for the user accounts too. You can use the tool delegconfig to troubleshoot this.
what is mean by "Claims-Aware WCF Service"
Is it a standard?
https://msdn.microsoft.com/en-us/library/hh545447(v=vs.110).aspx
A couple of clicks away from the page you linked: Getting Started With WIF > Windows Identity Foundation > Claims-Based Identity Model:
When you build claims-aware applications, the user identity is represented in your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.
Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for the following:
Authenticating users.
Storing user accounts and passwords.
Calling to enterprise directories to look up user identity details.
Integrating with identity systems from other platforms or companies.
Under this model, your application makes identity-related decisions based on claims supplied by the system that authenticated your user. This could be anything from simple application personalization wit
In my Windows Store App (c#) I have own authorization mechanism:
User past their account name / password and sent it to server.
Server generate unique token and returns it to user.
For all next requests user used this token.
Now I'm in trying to make authorization with using only Windows Account.
MSDN provide UserInformation class and I can get name for the user account or domain name for the user. But I thing this is not enough for my authorization scheme.
Also method GetSessionInitiationProtocolUriAsync looks very interesting, but I don't know how correct use such Uri for authorization.
How I can use Windows Account for authorization in my application?
note: I'm interested in both situation: when user inside domain or not.
Thanks.
There is numerous was to implement this but if you want to keep it simple and own the process you could implement your own authentication method which on a successful authentication you could build a hash value from their password and secret salt which could be returned to the user as a cookie etc. which you use to validate on every request there after.
On regards to authorisation you can implement your own or use a role based provider linked to the local machine group or active directory by using the classes below or just using the plain old RoleProviders.
You could implement your own method of authentication using the method described below or using the Authentication and Authorisation provider for ASP.Net (if your server runs on .net). Basically the Asp.Net Membership and role Providers. However the method detailed below will allow you to access and modify roles and other information about the user too.
In .Net 3.5+ there is a new namespace called System.DirectoryServices.AccountManagement.
Snippet from MSDN
The System.DirectoryServices.AccountManagement namespace provides
uniform access and manipulation of user, computer, and group security
principals across the multiple principal stores: Active Directory
Domain Services (AD DS), Active Directory Lightweight Directory
Services (AD LDS), and Machine SAM (MSAM).
System.DirectoryServices.AccountManagement manages directory objects
independent of the System.DirectoryServices namespace. Managed
directory services applications can take advantage of the
AccountManagement API to simplify management of user, computer and
group principals. Solutions that previously required intricate
knowledge of the store or lengthy code, such as finding all groups to
which a user belongs, are accomplished in a few lines of code with the
AccountManagement API.
You can easily authenticate a user credential on AD using the code below:
bool valid = false;
using (PrincipalContext context = new PrincipalContext(ContextType.Domain))
{
valid = context.ValidateCredentials( username, password );
}
If you want to validate using a local machine account you can change the constructor too:
new PrincipalContext(ContextType.Machine)
You can check the documentation for other options and additionally this will let you get all sort of information from the store like membership etc.
The new namespace was Microsoft attempt to simplify DirectoryServices which I think was successful but if you want even more control you could use the DirectoryServices classes but that would increase the complexity of the solution.
I hope this helps if you require further information or you think it is not quite what you are looking for let me know I will endeavour to improve the answer.
First, I'm afraid you're confusing authentication and authorization.
Authentication - proving a user's identity (like me presenting an ID when going to the bank)
Authorization - deciding whether an identity is allowed to perform some action (like whether the client "Nitz" can drain account #44422).
A Microsoft account can only provide you with authentication - the client will use some scheme to prove to your server that it belongs to bla#microsoft.com, and it's up to you to decide if it is allowed to do stuff in your application (authorization).
With domain accounts, you can use domain group membership to help with your authorization (it's even common in windows server applications), which you usually get "for free" with the user's authentication token.
Assuming I understood you correctly and you're indeed looking for authentication, you have to provide two behaviors - one for using domain authentication and one for Microsoft account authentication. This is because libraries and communication protocols are very different between the two.
Providing authentication
Using this this tutorial from Microsoft Azure's guys, you can set up a sample application / website combination that utilizes Microsoft account authentication.
To use domain authentication (kerberos / NTLM), you can follow this post and simply enable "integrated windows authentication" in your web site/service (I'm assuming it's IIS). If you're new to enteprise authentication, I'll shortly say that when set up properly (no time differences, AD issues etc.), the authentication is seamless. If there are issues, fall back to a simple "hello world" website and test it from Internet Explorer.
For each scenario, you best create a "hello world" method returning the user's authentication information, to make sure you got it right.
Providing authorization
with each authentication method you end up with a unique ID (Microsoft account: UserId. Domain accounts: SID). Your logic should translate this info to a set of permissions - e.g. Maintaining a table that has the ID in one column, and isAdmin in another. Your application should consult this logic when deciding whether to allow or deny an action from a client.
Combining enterprise and public
Since the methods to authenticate public users are different from the ones used for enterprise users, you'll probably end up with different IDs for the same user when connected from different methods (e.g. DOMAIN\bla and bla.blason#outlook.com). If you intend to provide both authentication methods at the same time, you have to account for that (for example, by creating a "user" table that has one column for Microsoft account IDs, and one for Domain SIDs). It usually makes little sense to provide both authentication methods at the same time, but it's your app.
Hope I helped!
Once i had the similar situation, (A client app need to connect to server with few identity credentials. after the custom authentication , a token will be grant for the client with few claims, then each client request will be validated against the given token) , if you are in something like this, consider this link, it helped me to solve the issue.
http://bitoftech.net/2014/06/09/angularjs-token-authentication-using-asp-net-web-api-2-owin-asp-net-identity/
Note: you can implement custom authentication, and authorization by extending claimsAuthenticationManager and Claimsauthorizationmanager respectively
I have a SaaS web application that caters to multiple education institutions. All clients are hosted in the same application/database. The application is currently written in C# for ASP.Net 4 Web Forms.
Currently my application uses a local/native database for user authentication/authorization.
Our clients are asking us to support single-sign-on where the client is the authentication provider and my application the consumer.
The problem is that the clients are asking for SSO via different protocols/mechanisms like Shibboleth and OpenID Connect. This means I need-to/should create a solution that works with all of these or that is at least extensible.
I came across Thinktecture's IdentityServer, which I think can abstract the various SSO mechanisms used by my clients and return to my app a claims based identity token that my app understands.
I'm struggling a lot with this concept though. Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user? How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)? Does the IdentityServer need to validate the existence of the user in my app's local/native database? Can the IdentityServer handle both SSO and local logins?
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server). But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it. ADFS may provide a similar solution, but most examples out there speak to ADFS and Azure.
Lastly, I'm assuming that I'll still maintain local/native authorization data about each user as the 3rd party authentication provider can't possibly know the specific authorization needs of my application.
Any thoughts or suggestions out there?
Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user?
Basically YES. But it depends on how you set it up. Your page could call Authentication provider of the client if you have only one client or one authentication provider. Or you could set up your local IdentityServer (more extensible IMHO) and configure authentication provider of your client as another IdP (identity provider).
How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)?
If you go with the second option then your app will redirect to IdentityServer and based on home realm it will be automatically redirected to IdP. If no home realm is specified by your application then IdentityServer will show all configured IdPs and user chooses what IdP to authenticate at.
Does the IdentityServer need to validate the existence of the user in my app's local/native database?
It depends on you. If you wish to verify the existence of the user in your local database then you may do so by extending IdentityServer.
Can the IdentityServer handle both SSO and local logins?
Yes, it can.
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server).
You can always use IdentityServer and integrate it in your local application. Or you can use Shiboleth as your local authentication provider. Both are implementing standards like WS-Federation, WS-Trust or OpenId and both are open source so you can extend/modify it to your liking.
But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it.
I can't really say how much documentation is there. But if you wish, NDC Oslo 2014 will feature 2 days of Pre-Conference Workshops where Dominick Baier and Brock Allen (authors of IdentityServer) will teach you everything you want to know.
I am developing an application where the security requirements for data transferred and access are fairly high. As I understand, Windows authentication is the preferred method for TCP over an intranet.
How do you deal with situations where Domains are not used and only simple workgroups are available? (Some customers will not be using domains to manage the networks).
Is using the interactive clients details (currently logged in user) enough, or should I get them to separately re-enter their username and/or password, as otherwise aren't I leaving security up to the network administrator to make sure they have an appropriate policy (ie. the computer is locked after a period of time)? This is particularly important as I know some of the users are prone to leaving their computers logged in, so how do I ensure that the account owner is the actual user?
If so, whats the point of using Windows authentication over say username/password authentication if they are just re-entering their authentication details?
Thanks
The point of using Windows authentication is to have a centralized directory for network objects management. If you have workgroups I say you better go with another technology, maybe membership provider and role provider.
This article talks about the cons of doing something like this.
The purpose of using Windows Authentication is to take advantage of the pre-existing membership scheme. In enterprise level development this means the administrator has the centralised membership control panel they are used to using to manage the domain level security. The additional benefit for users is a single login to the computer grants access to multiple applications without having to re-enter their details.
If you don't have domain level security already established and there are no plans to migrate in that direction the membership provider option would be the better option in aspnet. Obviously you will then need to plan how the enterprise would handle the maintenance of multiple login and authentication providers.
[Edit]
Ah...Igor got there first.