I have a web application developed using ASP.NET 4.5 and MVC 4. It originally used Form Authentication for users to log in, however, we are moving it to ADFS (WS Federation) authentication. The idea is users from my organisation (Org 1) and another organisation (Org 2) will be able to log in using ADFS (ws-fed).
ADFS is set up so when you navigate to the web application's URL it is redirected to ADFS log in screen. At this point, it displays an option for the two organisations, Org 1 and Org 2. If you belong to Org 1, click this button and the user has to enter their username and password. The same thing happens if you click Org 2 button.
The ADFS servers in Org 1 and Org 2 have exchanged metadata/certificates and the claim values.
When a user from Org 1 logs in, there is no problem, after successful ADFS authentication, they are redirected back to the Web application with the required Claims (the web app uses the info in these claims). However, when user from Org 2 logs in, they are authenticated but their Claims aren't reaching the web application.
Does the web application need configured to work with both ADFS servers from Org 1 and Org 2? My original thoughts were Org 1 (my own organisation), would handle all the ADFS authentication. The web app would point to it, and when a user from Org 2 tries to log in, our ADFS would redirect the request to Org 2 and then Org 2 would send the claims back to our originsation ADFS server and it would redirect back to the application with the Claims? Am I wrong in thinking this?
No, that's correct.
Two possibilities:
Org2's ADFS has the wrong claims rules
Your ADFS has no pass-through claims rules. You need these rules on your CP (for Org2) and for your RP
It needs these rules to pass through what it receives from Org2.
Related
I have a design requirement for an ASP.NET MVC 4 (.NET 4.6.1) app hosted on the company server (Not Azure) to do the following:
Check is user is authenticated via Windows Authentication
a)Yes - designate user as "authenticated"
b)No - use OpenIdConnect (OWIN) to authentication using Azure Active Directory.
Once authenticated use the standard [Authorize] attributes on controller methods etc. I have implemented Windows and Azure AD authentication alone is individual MVC apps but never together.
I have found several sources describing how to mix Windows and Forms authentication, but none for this combination.
Does anyone have insights on how this might be achieved?
I had a similar requirement a year ago and my approach was :
The users are redirected to input their AD credentials (https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/)
Once they are sucessfully logged in on the AD you will get a token.
Then I call the Azure AD API on their behalf using the token I just got. I woulds just call the /me endpoint that will return me the user personal details.
With the above response I just need to check if the email address matches the email address that was initially requested.
If it matches it means the user was successfully validated against the AD.
Then you can proceed and issue that user a token or cookie to access your application.
We are going enhance the authentication and authorization system of our Intranet web app. After having few days reading about ADFS, STS, claim based authentication, asp.net Identity. Still not sure how these things works together.
Most of our intranet web applications are using Windows Integrated Authentication, we uses windows group or AzMan to do role base authorization. We have few applications(Vendor application) use it own user database and form base authentication.
We want to add following features to our web applications.
For Windows Authentication application, we want to let user to Sign Out / Sign in as different user. So when User A using his/her computer to access the application, it will auto logged in (default windows integrated authentication). When he/she do log out, it will redirect to a form to allow to input other user credential.
We want to allow user login to System A using System B username/password.
e.g. For the windows authentication application, we want allow user login to the application using the credential of the Form base application (Vendor application) of via visa
I don't know if ADFS can solve these two problems.
From my understanding, the main purpose of ADFS is to allow access to internal application from Internet, and it require SSL.
Our application all are in Intranet, and we don't want to manage the ssl cert.
But by using ADFS, perhaps I can enable both Windows and Form Authentication on my application, so then let use log out and re-direct him to the login form as which just like he access outside company network. It should solve the problem 1.
For problem 2, what if I can create a custom STS to issue security token by using the user database of the form base authentication appliaction. Then I can use claim based authentication and allow one application can use ADFS and my STS. It should solve my problem 2.
Is my direction correct? or am I complicated the problem?
ADFS will not work without SSL.
Furthermore, all RP have to use SSL.
Internally, users will be logged in seamlessly using WIA. When they logout, they will simply be seamlessly logged in again.
Also ADFS v3.0 and below can only authenticate against AD.
While what you want is possible using ADFS, the question is whether it's a good idea and worth the trouble. It may be more appropriate to ask the user to log out of the machine and log in with a different account so you can stick with Integrated Windows Authentication (IWA). Writing your own security infrastructure is fraught with peril.
If you really feel these are hard requirements and it is worth the trouble, the following may work.
Write an ASP.NET web application based on Katana and enable Integrated Windows Authentication. This will make sure that the first time a completely unauthenticated request comes in, the application will challenge the browser. Subsequent requests will have a WindowsPrincipal populated in the HttpContext.User and Thread.CurrentPrincipal.
Now, write a piece of OWIN middleware that checks if an authentication cookie is present. If the cookie is not present, it checks the Thread.CurrentPrincipal and serializes the claims into a secure cookie.
If the security cookie is present, it overwrites the WindowsPrincipal in Thread.CurrentPrincipal with a new ClaimsPrincipal created from the claims in the cookie.
Now, when a user navigates to the web application the first time, he/she will be logged in automatically using IWA and the cookie will be created. Now, provide a logout action which deletes the authentication cookie and presents the user with a username and password dialog.
In the POST handler for that action, use WIF to talk to the username endpoint in ADFS (using WS-Trust protocol) and try to authenticate the user with the supplied credentials. If successful, use the claims from the returned token to create a new authentication cookie.
We are trying to implement single sign on for two different web application located at different domain
WebApplication 1 (this will act as a front end where user log in)
WebApplication 2
the basic usage idea will be
User sign in trough a login screen in WebApplication 1
User click on a link in WebApplication 1 which will then open a popup screen to WebApplication 2 without signing in again
Now in order to achive this we created an ETL script which runs every 1 hour to synchronize the user and group accounts from web application 1 database to web application 2 database
Question
is there a better way to achieve single sign on rather then writing
a script that synchronize user account every 1 hour?
I have read new technology call WIF(Windows Identity Foundation) that is built in to .net framework 4.5 will this help to solve my issue above?
Running a script every hour is not a good idea as it be overhead on the server
To achieve single sign on for the different domain can be bit tough but not really impossible, It becomes difficult only because we cannot share the cookie across different domain. So we can have one different server for single sign on
When the user visit the web-application 1, redirect user to SSO server.
Once the user is redirected to the SSO server, check if the cookie exist, as its for the first time there will be no cookie so show the login page which is hosted on SSO server.
After getting the credential from the user validate the user
If the user is valid, generate a token now this token can be unique hexadecimal number or hash for the timestamps.
Set this token into the cookie on the SSO server and redirect the user back to the original site or success page
Now when user visit the web-application 2, redirect the user to the SSO server again
Once user comes to SSO, check for the cookie, if it exist and not expire then redirect user directly to the success page without asking for login credential again or show the login page and follow the drill again
As we are redirecting the user on the different server, we can set the cookie there with the common name as 'SSOcookie' and every time access the same when coming from different application. This will help you to achieve single sign on for different domain.
in default website i have 2 asp.net web application App1 and App2.both has same login control when user logins username and password is validated in users table in sql database.logined user information are stored in 3 session variables.
after login app1 redirects to profile.aspx and app2 redirects to dashboard.aspx.
profile.aspx has a link app2 and dashboard.aspx has link app1.if user clicks on the link he should be already login for that application.
if user logout from any one application he should get logout for both application.
how to put above sso feature in my App1 and App2
I suggest you take a look at Windows Identity Foundation.
Are the applications going to be in the same domain? If it is then all you need to do is set the forms authentication of App 2 to App 1 or the other way around, and make sure you have the same machine key specified for both applications. This article gives more explanation on how to implement SSO in sub-domain:
http://www.codeproject.com/Articles/27576/Single-Sign-on-in-ASP-NET-and-Other-Platforms
I am assuming forms authentication is used in your application. Forms authentication generates authentication ticket to validate consequent user requests and uses "machine key" to sign the authentication ticket. By having same machine key for all applications will resolve the issue. However, there are different scenarios to be considered depending on the scope of the applications which needs to be integrated.
Configured as virtual directories inside same domain
Configured as sub domains
Completely two different sites
1 and 2 can be resolved by specifying same machine key in web.config.
3 requires custom solution such as passing encrypted parameters via query string.
More information on machine key can be found here.
Here is my problem :
1) I have an ASP.NET website which is the main entry point in the application.
This website uses Forms authentication, which validates credentials (username/password) against a database.
2) Once logged on the website, the user is displayed a page containing several links which point to a Sharepoint 2007 application, where authentication is managed by an Active Directory.
3) Every user in the Active Directory is duplicated in the database managing the ASP.NET website authentication.
4) The ASP.NET website and the SP 2007 application are NOT on the same domain.
The problem we are facing is that the users first have to enter their credentials to access the ASP.NET website. Then, clicking on a link pointing on the SP 2007 application, they're prompted another .htaccess-like window in order to authenticate them against the Active Directory.
The question is :
Is it possible to kind-of pass the credentials the user first entered to access the ASP.NET website in the HTTP context so that when he clicks on a link pointing to SP 2007, he's not asked to enter his credentials again ?
I've already successfully validated credentials against an AD, but I'm stuck at where do I have to extend the ASP.NET authentication process so I can inject the SP-related domain credentials into the context.
Hope I was clear, feel free to ask for more information if needed.
And just to be clear, bypassing the first step (ASP.NET website authentication) is mandatory :-)
Thanks everyone,
Mick
Does sharepoint have ntlm or forms based authentication? (I'm guessing ntlm because of the login poup)
I have built something like that with sharepoint forms auth where:
1.User logs into ASP.NET application
2.Auth cookie created
3.Auth token stored in database
4.User goes to sharepoint
5.Custom HttpModule checks cookie and token
6.Logs user into sharepoint using HttpApplication.AuthenticateRequest and FormsAuthenticationTicket
I suppose you could do something similar with ntlm auth but it might not be possible as the browser is doing the authentication. A whole bunch of different headers get sent. (eg WWW-Authenticate Authorization). It must be noted that developing a custom HttpModule is not a novice task.
You said:
3) Every user in the Active Directory is duplicated in the database managing the ASP.NET website authentication.
I hope the passwords are not clear text in that database
And said:
And just to be clear, bypassing the first step (ASP.NET website authentication) is mandatory :-)
Do you mean "is not mandatory"?