Currently I have a code modules which contains code necessary to authenticate user credentials and it includes AD users validation also. now I have a requirement to auto logging in without prompting the user to enter username and password if the user browses the application from company's network domain.
Can it be done via Single Sign on?if so how to implement it?
I believe the easiest way would be to use Integrated Windows Auth and ensure your computers are connected to the domain, and then the computers are set to have your host in the "Intranet" zone in IE, therefore your credentials would be passed. If this isn't an option perhaps take a look at ADFS or OAuth where you can implement SSO across many sites using Cookies, Tokens, Claims, headers, etc.
Thanks!
http://technet.microsoft.com/en-us/library/cc754628(v=ws.10).aspx
yes, you can implement sso via cookie, if you have cross domain request in iframe in IE browser, please remember to add P3P in http response header when set cookie
Related
Should I Create only one client and all my applications must connect to the identity server using it or there is configuration should I do to make it work?
Identity Server is Web API, grant type is "resource owner password".
Each application is a client. But whether you should use the same client_id is up to you. Personally I use different client_id's for each instance of an application. This helps me to identify the instance and allows me to use different secrets per instance. And I think that the client_id has to be unique when you are using refresh tokens.
SSO is something you get for free when you use OpenId Connect (oidc). It works because of a cookie on the IdentityServer website:
When a user has to log in, the user is redirected to the IdentityServer website where (after succesful authentication) a cookie is set, containing information about the identity of the user.
When the user is returned to the client (after succesful authentication) the client will also set a cookie. As long as this authentication cookie is available, the user will be logged in.
When the user needs to log in again, because the client can't authenticate the user (anymore), IdentityServer will try to identify the user with the information from the cookie on the IdentityServer website and (if succesful) automatically sign in the user, skipping the login form.
But it seems that your setup has nothing to do with oidc. When you say that IdentityServer is a Web Api then this suggests that the user is not redirected to the IdentityServer to login, meaning that there is no opportunity to set a cookie.
And Resource Owner Password Credentials (ROPC) is an OAuth2 grant type. This suggests that the user performs the login on the client.
In order to enable SSO, the user has to login on the IdentityServer website. While ROPC is still possible, you'd better use one of the recommended grant types.
We have an ASP.NET/MVC website that's using FormsAuthentication. As is usual, when the user tries to access a page, and doesn't have a valid FormsAuthentication cookie, IIS redirects him to the login view. When the user does a HttpPost to the login controller, our controller action makes a call to our WebApi webservice, which validates username, password, and customerid against a Sql Server database. If the authentication passes, the controller action sets a FormsAuthentication cookie, and redirects to the page the user had asked for.
Now sales is making noises about "Single Sign-On", though I'm not clear exactly what they mean by that. From what I've read, in the Microsoft World this usually means accessing MS's Active Directory Federation Services.
At this point I have almost no idea how this would work, but before I dig into this too deeply, would it be possible to put the authentication code within the WebApi webservice, where we could choose to validate against the Sql Server database, or against whichever ADFS server was appropriate for the specified customer?
Our problem is that we have I don't know how many thousands of users, working for some hundreds of customers. Many customers will not have ADFS running, and those who do will each have their own ADFS server.
Most of what I see with respect to Single Sign-On seems to involve doing browser redirection to the ADFS server, then redirection back, and looks to be avoiding login at all, if you're already logged in. I don't think we can do that, in our case. We can't know which ADFS server to redirect to, until we hit the database.
So, the question - is it possible to do ADFS authentication entirely from C# code in our WebAPI web service?
(One possible complication - the website itself has zero access to any database. The sole configuration setting in its web.config is the base URL of the webservice. Whatever authentication happens has to happen in the webservice, not in the website.)
First of all, "Single Sign-On" (SSO) is not limited to ADFS. It simply means that you type your credentials only once, and then all systems you access automatically "recognize" you; all subsequent authorizations request are transparent. For instance, if you have several web sites using Windows Authentication in your company Intranet (same AD domain), you have SSO: you authenticate once when you log in to your computer, and then your web browser authenticates automatically to these web sites using NTLM or Kerberos. No ADFS in this case.
What ADFS (and "Federation" more generally) allows, is SSO accross security boundaries. In Windows world, a security zone is typically created by an Active Directory forest; everything within this forest is accessible using SSO provided by Windows authentication. But as soon as you leave this zone (SaaS application, web site in another company network), you need another authentication protocol to perform SSO, and these protocols are implemented in ADFS.
Then about your particular problem:
What you could do is instead of using FormsAuth, you use AdfsAuth. When a unknown user accesses a page, he would be redirected to ADFS for authentication (using browser redirects as you correctly mention). To know which ADFS server should authenticate your user, you need a way to differentiate them indeed: a list of IP range per customer? a different URL per customer? If you don't have something like this, then the only way is to show them a list of choices such as: "I work for CompanyA", "I work for CompanyB", "I work for CompanyC", "I don't work for any of these companies and want to authenticate using FormsAuth."
In this case, what your WebApi web service has to do is: if I know which ADFS server to use, redirect the user there. Otherwise authenticate the user as usual using the database.
When you use AdfsAuth for a customer, your database is useless. You can delete all credentials related to this customer.
do ADFS authentication entirely from C# code in our WebAPI
Well it's possible to "re-implement" ADFS in your service, but you won't get SSO if you do that. When you use federation, your redirect the user to the ADFS server of his company. This ADFS server is in the same domain as his computer, so the user gets SSO here. Once again, your users can't get SSO if you authenticate them yourself, because your users are not in the same security zone as your site.
When authenticating to multiple identity providers, it is typical redirect to your own STS. So, in this case, you would have www.yourapp.com redirecting to sts.yourapp.com, which redirects to sts.somecustomer.com.
The specific tools to enable such a dataflow is the home realm parameter (whr), and the AD FS Powershell API (to allow IDP maintenance).
Your RP-STS acts as the trust-point for the app, and manages selection of the appropriate IDP. One RP-STS, many IP-STS's. Each of your Customer's IP-STS gets set up as a Claims Provider Trust in AD FS.
As always, Vittorio has already covered the subject better than I could.
I have an .Net MVC3 website with multiple authentication options:
Facebook
Google
Websites own
When the user initially browses to the site he is asked for his/her choice of authentication and once they have either registered or logged in through a third party they are authenticated on my site.
My questions are:
Is it possible to save the user's authentication choice in a cookie, so when they revisit the site they are logged in using their previous authentication choice (Google and Facebook automatically if they are already logged in)?
If possible whats the best practice for creating a secure cookie in MVC3?
Cheers
I think this could help
THIS
or
THIS
It can also be implemented in server side too.
You could use the SAM:
http://brockallen.com/2013/01/26/replacing-forms-authentication-with-wifs-session-authentication-module-sam-to-enable-claims-aware-identity/
This would allow you to issue a secure cookie that contains all the claims from the identity provider.
I'd like to create a single sign on for multiple websites (sitea.com, siteb.com, sitec.com). All sites are with the same company. Any database is also with the same company/location. Some are asp.net web apps and some are forums. I'd like to try and abstract away the SSO so it is not tangled up with any one site. I've outlined my approach below:
user signs into sitea.com, which authenticates user. A sessionid is created by sitea.com.
a cookie is placed on the user's machine with username and sessionid. The sessionid is inserted into the database centralAuthDB, which all sites have access to.
user clicks a link in sitea.com that does SSO to siteb.com (forum).
siteb.com retrieves username and sessionid from the cookie. siteb.com then checks these credentials against centralAuthDB.
A match is made with centralAuthDB and the SSO is authenticated. However, the forum (siteb.com) also has its own database of users. The username is checked in this database as well and now the user is seamlessly logged into the forum.
Is the above secure and practical?
Should credentials be send to centralAuthDB via webservice?
Will the cookie need some generic name? Then the values for username and sessionid are placed in this cookie?
With any SSO, you're going to need a service that takes a credential and generates a secure authentication token. The token must be encrypted so that it cannot be forged; only the authenticating service would be able to decrypt it to check for validity. Then, that token can be passed around to whatever you wish--in a query string, most likely. Cookies are ruled out because they are inaccessible across host names.
As mentioned in the comments on your question, it's wise to investigate pre-existing solutions to this problem. Way smarter guys than you or I have spent thousands of man-hours hashing out all the problems with such systems.
My own personal choice would be OAuth as it's the implementation I'm most familiar with. You might also want to check out how Facebook does authentication for ideas on what, exactly, the token could contain.
We're looking into doing machine-based authentication, allow any user on particular machines to access our .Net site. The list of machines will change but are all on an internal network. Their IP addresses are assumed to not be static.
To make it more manageable we'd like to be able to restrict access to an Active Directory computer group.
I can manage the AD querying, my question is where is the best place to pull out the machine name and authenticate the entire session?
I looked into creating a new HttpModule but it seems I'll have to authenticate every request. Authenticating every request doesn't seem ideal if an AD query is involved.
The web is stateless, so every request is always authenticated no matter what technology you're using. However, the trick to not hammering AD is using a session http cookie. You would set this cookie on the first request and check for it on subsequent requests. You would need some kind of cryptographic protection on the cookie, but thankfully this is ready-rolled in ASP.NET. I'd say you could leverage the Forms Authentication infrastructure to set and validate a cookie - you would just offload the initial authentication to AD instead of reading from a posted form.
Here's a great place to start:
Understanding the Forms Authentication Ticket and Cookie
http://support.microsoft.com/kb/910443
You don't need to authenticate every request. Authenticate the first request with your HttpModule, and either add the requestor to the session, or cache the credentials for a short period of time.