I have a very simple implementation of the AspNet.Identity apiservice using Entity Framework that hands out tokens that cam be used to authorize requests through out all the services and web sites. Users have claims to identify what they are authorized to do within our system. Some of these users (internal users) will have also have AD accounts and rather than have them have to remember different passwords I would like to authenticate through AD for these users then use the AspNet.Identity.EntityFramework to add claims. Ideally if a user is already logged into the domain on there PC they would not even have to enter their password.
How can i get our AspNet.Identity implementation to validate with AD?
I have already seen this question Use ActiveDirectory authorization with ASP.NET Identity but I am not using the ThinkTecture Identity Server and it seems to be using something other than AspNet.Identity and I do not want to replace our current implementation.
Can anyone give me a course of action or point me towards a tutorial that accomplishes something similar?
It depends. VM, Cloud, Local Machine? If a machine on the network, could be different. Either way you will have to modify your web.config to gain access to your membership provider in order to achieve the seamless route presented in the link below.
This link,
https://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication, should help you get in the right direction as to setting up IIS*. Hope this helps.
Related
I'm somewhat new to ASP.NET MVC and I hoped you can help me with authentication for my app.
I have a MVC application that needs to be authenticated using SQL Server Log Ins. This means I have to create roles and users in SQL Server, and all security permissions are managed at Database level. Roles, users, and permissions aren't constant and we should be able to manage them.
Any suggestion? Is there anyway to override default behaviors of Identity to achieve this goal? What do you think is the best way to implement this need? Should I Use AD or DB Logins are fine?
Thanks in advance
Based on my working experience with diverse login mechanisms, I would like to suggest you the following route
Choose AD as your identity provider[IDP]
Register your application as an Relying Party [RP]
Get the federation metadata from AD to set up your application
In case you have your AD Server with ADFS 3.0, refer this link for a sample
In case of going through the OWIN Federation Middleware, it should be very easy for you with little development effort as given in this link
With ASP.Net MVC5 & Owin this task of yours should be a piece of cake
For Azure AD based samples, refer here or for first hand information, read this article
I've found a lot of information about this subject; however, not much in the way of how to implement my specific scenario. Unfortunately, my company's AD is half-pregnant, so to speak. The users are there, but that's about it.
I'm creating an intranet and obviously need to authenticate users which I'll use Windows Authentication to do so. However, since my AD does not contain any of the additional information typically used in an intranet (heirarchy of users, meaning managers and departments associated with each employee, etc.), I wanted to use Identity to satisfy that need. And although we do utilize AD Groups, it's painfully difficult to get that setup and want to use Identity for role based authorization instead of AD.
Although fairly new to Identity, it's easy enough to figure out, and Windows Auth is easy to implement.
What I'm missing is the know-how to marry the two together.
So my scenario is - Authenticate the users with Windows Authentication. Once authenticated, switch over to Identity for role-based authorization (claims?) and any other meta-data (such as user information or application specific data)
I've seen this question asked, but not sure if it really is that simple or is there more to it. And I'm not sure if it really fits my scenario. And this question seems to be exactly what I'm asking, but no responses. Finally, this question seems even closer to what I'm asking, albeit using the Membership Provider. I'm guessing this may be the way with Identity as well?
So, in my instance, I'm using Windows Authentication and so I will not have a login form or action (strict requirement to NOT have users enter username/password - it should be seemless). In the case of an employee going to the intranet for the first time, they authenticate with AD, but then how would I save that user to the Identity store? Would it make sense to send new users (employees that have never been to the intranet before) to a Register page after they've been authenticated through AD to ensure there's an associated record in Identity? I could then, as part of the registration process, have them select their department and manager. After they register, a human-based validation process would have to happen to ensure the user selected the correct department and manager, but that's the least of my worries right now.
Recommendations, links, or just some simple guidance would be appreciated. Thank You!
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 am trying to use the Identity Framework to connect to Active Directory. I have followed the directions for setting up a new MVC project and changed the authentication to Organizational Accounts, then it asks for an On-Premise Authority. That should be a URL that points to the metadata document. From everything I can find, that means you need to have Active Directory Federation Services setup, which we do not yet. My question is, is there a way to use the Identity framework to connect to Active Directory without ADFS? It seems like this should be a really common situation, but I cannot find anything on it.
If this is possible, do you enter something else in On-Premise authority line, and what would that be?
It doesn't have to be adfs, it can be any STS that supports passive ws-federation protocol.
You can either use adfs, the thinktecture identity server or even craft your own simple sts that would consist of two pages, a login page and a ws-fed endpoint. Crafting your own sts is not that difficult if you know how. There are tutorials available, I wrote a tutorial by myself once.
http://www.wiktorzychla.com/2011/08/quest-for-customizing-adfs-sign-in-web.html
I have an Azure account and currently a Mobile Service setup with a SQL Database so that my Windows Store app can communicate with the database.
I have developed sites using ASP.NET WebPages authentication. And I need something similar for my Windows Store app.
I have successfully gone through the documentation and tutorials on the Windows Azure website and implemented ACS (Windows Live ID, Google, Yahoo!, and Facebook) - but the thing is - I don't want Google, Yahoo!, Facebook or even Windows Live ID or Microsoft Account) logins - I want my OWN login but it seems that they don't give you this option (correct me if I am wrong).
I need to allow users to signup from within my application (that means, providing their name, DOB, email, phone, address, etc) and shove it all in my database.
Now, after implementing Microsoft Account login with my Azure service, I found out that you can't even get the most basic information about any user who has logged in to your application - not even an email address.
I have spent hours searching online for something that could possibly help but I am running out of keywords - and have not hit a single related result yet.
Does anyone know if this is possible? How would we go about integrating login and signup with a Windows Store app that set/gets this data into/from a Windows Azure service?
Any code, samples, links, tutorials, documentation, etc would be highly appreciated.
You have gone down the road of hooking up external identity authentication, which in my opinion for an external facing web application is a better approach. Benefits are:
Your application is only responsible for Authorization not Authentication. There is a whole lot of work involved in Authentication and a large number of best practices. Best let those who know best take the burden of this. This doesn't mean you shouldn't try and understand it though.
If your site gets hacked you don't have to tell them that their username / email and password combo has been compromised and they will probably have to change there passwords on other sits.
You are also making sure that your users don't have to remember / manage yet another username / email address password combo
If you really want to do the Authentication then that is fine but you will need to do it yourself. Have a look at examples on Asp.Net Membership. This is not the only way and nor is it the best way but there are lots of examples.
Now if you decide you want to use external authentication I can give you some pointers to help with your current implementation.
First thing to note that the Id you get back from Live, Google, Facebook can only be assumed to be unique for that provider. Therefore if you want to keep a profile in your system for that identity and you want to use more than one provider you will need to implement it in such a way that you can keep the id unique in your system and help you associate it with a provider.
Website Authentication with Social Identity Providers and ACS Part 2 – Integrating ACS with the Universal Profile Provider
As you have found out not all of the Authentication providers return the same "claims". A claim is something that user claims to have, such as an email address, name, date of birth, etc. All the ones you can use by default via the ACS return Uid and some return a name and email address. What you have to do is fill in the gaps. When someone registers you will need to pull the relevant claims and then ask them to fill in the missing ones. You may also want to map the different claims in the ACS to a common name that you can use in your app as one provider might use slightly different names.
Federated Identity with Windows Azure Access Control Service
Just because you do not handle Authentication you still need to be responsible for keeping your application secure. Half of the work has been done for you so your code should be a lot lighter but you will still need to make use of roles.
Windows Azure Role Based authentication (ACS)
The really nice thing about this approach is you can implement your application the same why SO have done with there identity model. You can allow users to associate multiple identities against their profile meaning they can login how they want to.
If you choose not to use the built in providers for ACS you will need to implement your own Identity Provider using SAML, OpenId, etc...
You can look into the Windows Identity Foundation (WIF) for implementing WS-Trust or WS-Federation.
There is also ADFS which has the same set of support but uses Active Directory with WIF and Azure has its own version of AD that can be used.
There is also thinktecture identityserver which can jumpstart your venture into IdP land, but I have not used it myself yet.
If you want to go the OpenId route there is DotNetOpenAuth.
If you're looking to add custom identity to your Mobile Services app, check out Josh's post on custom auth: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx