For the purposes of custom authorization I need to find out who the current user is so I can determine if they are authorized.
Can I use the [Authorize] Attribute to force Windows Authentication?
Can I then use Thread.CurrentPrincipal to determine who the user is?
Related
I am working on a Intranet application where i am calling a SAP service from a ASP.NET WEB API, Currently it is working fine with a HttpBasicAuthentication with a predefined user name and password. But now the requirement is to get the logged in windows user's user name and password through ASP.NET WEB API and pass it to the SAP service for authentication? Can anyone help me on this?
1) HttpBasicAuthentication won't apply in this case.
2) Use identity impersonate via the web.config tag (ref Identity Impersonate) to have the current user's identity taken up in api. However this will only work for Intranet based applications and not over internet. For Internet based, you will need to have Kerberos bridge (somewhat complicated) concept implemented.
3) In you app.start method, you need to set the current principal to windows principal.
Then you can have the user detail available..
Please note that you will not have the user's password available as OS protects that very very securely. You can get the user's Kerberos token though which your target system can auth against the AD being used.
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.
I am working to move an ASP.NET MVC site currently using FormsAuthentication to use SSO (Webgate/OAM).
The Webgate is installed and exposed thru an ISAPI filter on IIS and redirects to SSO page.
In FormsAuthentication, we would get HttpContext.Current.User as IPrincipal. But with SSO authentication, IPrincipal in HttpContext.Current.User is no over available.
This documentation from Oracle says that protected ASP.Net should expect WindowsPrincipal as its IPrincipal. But replacing HttpContext.Current.User with WindowsPrincipal is not helping either.
Is there a way I can capture the identity of authenticated user inside ASP.NET application?
Time revealed that when SSO redirected authenticated user, back to my app, it shared username in HTTP headers. I realize I should have dig thru the SSO response.
Anyways, I was able to capture the identity of the user and set up FormsAuthentication cookie with this identity. This approach left me here, if anyone has an interest to follow it.
OAM 11g Now supports OOTB integration with the .Net Applications (MVC). You can refer the http://howtoidm.blogspot.in/2015/03/oam-11g-net-application-integration.html
I've implemented a custom ASP.net membership provider to deal with forms authentication. The custom provider uses a custom User object for authentication and authorization. I was wondering If I can pass this object to each WCF call without adding it to the parameters list?
Since you are already using a MembershipProvider you can utalize that on wcf as well so both are secured by the same mechanism.
See this post on msdn.
Windows Communication Foundation (WCF)
developers can take advantage of these
features for security purposes. When
integrated into an WCF application,
users must supply a user name/password
combination to the WCF client
application. To transfer the data to
the WCF service, use a binding that
supports user name/password
credentials, such as the WSHttpBinding
(in configuration, the wsHttpBinding
Element) and set the client credential
type to UserName. On the service, WCF
security authenticates the user based
on the user name and password, and
also assigns the role specified by the
ASP.NET role.
Another option would be to create a custom IAuthorizationPolicy that pulls off your user via
OperationContext.Current.IncomingMessageHeaders.GetHeader<T>
And than setup your principal like the following:
evaluationContext.Properties[Constants.EvaluationContextPrincipal] = principal;
Here is some more information on creating a custom IAuthroizationPolicy. With this method you could achieve what you want without passing your user to the method.
Just be warned if you go this route a crafty person could end up impersonating the user by simply suppling a bogus user in your header.
Using the asp.net membership provider for wcf would most likely get you what you are really after plus adding some security.
You definitely should not add this to the parameters each method.
I do not know about your custom user object but as far as WS* and most security standards concerned, your user object will have username and password.
The answer depends on the binding you use. BasicHttpBinding or BasicHttpContextBinding can use HTTP authentication schemes while WsHttpBinding can use custom Message security which you can provide user name and password.
BasicHttpContextBinding is especially good since it can work with ASP NET session.
We have a SSO solution with ADFS for logging into our web app, we also have standard setup that uses authentication with our database. I want to setup a solution that allows for both. So now I am trying to figure out, is there any way for ASP.NET to detect if a user is authenticated with Active Directory so I could do this on the fly? If user is logged in through AD, send through ADFS, else, show login screen. Any idea?
I also realize that this may not work if they are setup to use forms based authentication only after the ADFS process is started.
Yes... In IIS, enable both integrated authentication, basic, and anonymous. All the real work is done in HTTPModule that are registered in the root Web.config (e.g. in the runtime CONFIG folder). The built-in Authentication HTTPModule will set the user Principle once authenticated if authenticated via integrated credentials. You can add your own to be fired after it. If the IIdentity (e.g. User.Identity) has the IsAuthenticated set to false then you know they were not authenticated and can then redirect them. If it is set to true, you can then replace the IPrinciple with one that contains roles that are germane to your application.