I have an application that authenticates user using a remote system. Users in remote system don't have any role because its multiporpuse nature. I want to assign some roles to each user that authenticated and is valid. Can I use custom membership and rolemanagement? Can I use a dynamic access level to inject authorization to pages?
Yes, you can. I am doing something similar in some apps. Just use the remote system to authenticate, but if authenticated create (or reuse on multiple visits) a local user using membership. Then you can assign roles to that "local user".
So the remote system is only used to authenticate/validate a users credentials, but anything else is managed localy using memberhip and its role management built into ASP.NET MVC.
Related
I've got a user authenticated via IdS4, along with a few claims and a role, now I'm lost about what to with it. The general flow for the user is: Go to my site, log in redirects to IdS4 server. They enter their username/password, and redirect back to my site, along with cookies set.
I've not seen much beyond authentication in the tutorials I've found.
Should/How do I persist the user? Should I set up Identity on my MVC site? I'm just looking for a general idea, I think I can figure out the specifics, at this point my general Googling hasn't turned up much.
Thank you.
You can add ASP.Net Identity to manage users in your client MVC application , or directly use EF Core to store users in database without ASP.Net Identity .
But the problem is why you want to perisit or manage users in your client application ? You are using Identity Server to do authentication and IDS will connect the database/configration file to validate user and fill user claims , if you want to manage users/roles , you can add apis(CURD operations to user database) as protected resource , and your client app acquire access token to access that apis to perform user management . So that user management operations are share to clients which have permission to get api's access token . But if you want to manage specific users which only available to one client , you can mix asp.net identity and IDS4 authentication in client app .
I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?
You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom ClaimsAuthenticationManager class deriving from the base ClaimsAuthenticationManager and overriding its Authenticate method. This is a normal extensibility point of WIF. WIF will
get hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx
Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.
If encryption is used via ProtectedData CurrentUser and I have a site using Forms auth (with a custom membership module, don't think that will make a difference), will it work across several different web servers?
My guess would be that it would if the current user that is used is the User.Identity, 'cause that will be the logged in user, and will be the same on any web server.
The docs didn't seem to say anything about it working with ASP.NET.
The "current user" will be the user the asp.net application is running as (not the user accessing the site). Typically this is /ASPNET user account however it can be changed. You can verify this with the WindowsIdentity.GetCurrent() function.
Your other option is to use DataProtectionScope.LocalMachine to store it in the machine store instead (acceisslble from any account on the machine). While this may seem less secure member if you are using an unprivileged account (like ASPNET user) than anyone could write an app to run as that user and gain access to that user store.
Just going to start making a web application and was wondering which was better, or at least what are the main differences between them (as it probably matters what I am using them for)?
Windows Authentication
Passport Authentication
Form Authentication
I would say it greatly depends on what your web app will be doing, as each one has its place. Here is some brief details about each one.
Windows authentication enables you to identify users without creating a custom page.
Credentials are stored in the Web server s local user database or an Active Directory domain. Once identified you can use the user s credentials to gain access to resources that are protected by Windows authorization.
Forms authentication enables you to identify users with a custom database such as an ASP.NET membership database. Alternatively you can implement your own custom database. Once authenticated
you can reference the roles the user is in to restrict access to portions of your Web site.
Passport authentication relies on a centralized service provided by Microsoft. Passport authentication identifies a user with using his or her e-mail address and a password and a single Passport account can be used with many different Web sites.
Passport authentication is primarily used for public Web sites with thousands of users.
Anonymous authentication does not require the user to provide credentials.
http://msdn.microsoft.com/en-us/library/eeyk640h.aspx - ASP.NET Authentication further details on forms and window authentication
Edit
Rushyo link is better: http://msdn.microsoft.com/en-us/library/ee817643.aspx
Situation as when you can use what :
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.
This should cover everything you're looking for (and more):
http://msdn.microsoft.com/en-us/library/ee817643.aspx
[Snap - I was totally going to use that exact same quote as well ;)]
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.
Client requires major applications to provide users with “single sign on” authentication feature based on the corporate solution (Active Directory).
This means the business application trusts the credentials provided by the browser and does not request user to provide standard login/password pair. The server/browser trust is built on Windows Integrated Authentication mechanism.
Ours is an ASP.Net Web application on dot net framework 2.0 hosted on IIS 5.We need to implement the SSO feature.How do we do it?
I'm pretty sure this is the same requirements that almost all intranet apps follow.
If you just enabled Windows Integrated Logins in IIS, then you'll be set for the #1 item.
I don't know if #2 is even possible, because it conflicts with your other requirement. The browser only passes the locally logged in user's credentials (as required by #1). If you built a web form to authenticate via AD, then you would be in violation of the requirements listed in your narrative/paragraph.
What do your clients think #2 really means? What do they want here? A way to log in as a different user? They can just log off the computer and log in as the other user.
In general, SSO requirements are best addressed by Claims-based protocols such as WS-Federation or SAML 2.0. In principle, you can implement these protocols yourself since they are open standards, but it requires a lot of specialist knowledge.
The new Windows Identity Foundation (formerly known as Geneva framework) contains protocol implementations that can enable SSO scenarios, although it will require you to upgrade your platform.
Use Custom Forms Auth instead that wont ask user to enter ID and password.
Prerequisites:
1> Database table having user details such as email, role etc
2> Enterprise active directory where user profiles are stored
3> Write a VBCOM or ActiveX or other components that can read user's domain and name from the windows machine through browser.
Steps:
On pageload for all the forms call the component<3> to connect to Active Directory<2>. That method should read current user's name, domain from windows system.
Search AD with these details. If exists then query and extract the email address or whichever is the unique key in the AD user profile.
Using this key query the database<1> where you stored application specific user details such as email, roles.
If user email from AD match with email in Table then grant the user appropriate rights else deny access if user does not exist or role is null/restricted.
If valid user then create a cookie that is encrypted and can be read by other applications to really implement any sort of SSO.