I'm writing service which will use for sending emails in my ASP.NET project. I tested two approaches for autentification on Exchange:
Since my service is running under
local user I allowed for it an
anonymous access and pass login and
password to Exchange Server.
Another way is domain authorization
on Exchange: before I invoke
smtpClient.Send() method I
impersonate(in code) an exist domain
user with access rights to sender
mailbox.
All of this ways works well but I really little confused how it should be as a good scenario. If I have a feature for sending mail on my ASP.NET site and Exchange Server -- what type of autentification on Exhcange user policy is preferable (1 or 2, ...)?
Option 3: Configure your service to run with a domain user account.
If so, this would be the preferred option, IMHO. Exchange can then be configured to allow access to a know domain user, avoiding the need to require anonymous access and, importantly, you don't have to secure away credentials in your service configuration in order to impersonate a domain user.
Indeed, you could configure your service to run under the security context of the user that you're impersonating.
Related
General question. Server admin setup SPNEGO. The LTPA bullet is marked under Global Security in admin console. My understanding is that SPNEGO captures username from an initial sign-on (ie network). Later, if user goes to an app's URL, few of the many things happening is SPNEGO is going through user's ldap groups (admin console-securtity roles) trying to find group that is tied to app's role names. If match is found, user authorized and can go directly into app without having to use login form to enter credentials. But have problem trying to implement this. Checking HttpServletRequest - getUserPrincipal().getName() and getRemoteUser() at front end of app are coming up null. If SPNEGO is in fact setup correctly, should a null ever be found?
You are confusing a few things. SPNEGO is a mechanism to pass user authenticated in the Kerberos realm to the given service without need to pass user password. It has nothing to do with authorization - this part is done by WebSphere security service based on the id retrieved from the request (in short).
Null username usually is effect of not enabling Application Security in the server or not protecting application with Java EE security (security constraints defined in the web.xml).
For some basic information about SPNEGO in WebSphere, check the following page Single sign-on for HTTP requests using SPNEGO web authentication
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
There are a lot of articles talking about this error and how to resolve it. I'm assuming it is a semi catch all error report for different types of connectivity issues. Here is my scenario, I hope someone can help me to figure out what is wrong. I'm somewhat new to this.
I have a fax server using XMediusFax. I use their API to communicate with the server to send faxes and check the status of the faxes. My DLLs are all registered correctly on my machine, and I have the certificate setup under the Trusted Root Certification Authorities section.
If I call my code in a standard VBS script it works 100% fine. If I move the code into my ASP website it gives me the error: Could not establish trust relationship for the SSL/TLS secure channel. I opened IIS 7, went to my site, went to Authentication, selected the Anonymous Authentication option, and changed it from the default value of IUSR to my domain login. After doing that It works great from my website.
Modifying the Anonymous Authentication is not a solution I would want to roll out to customers. Does anyone have a less brute force approach that I could try? I did try setting my app pools identity to my domain account and that didn't fix the issue.
I believe that your issue may be caused by the fact the web service call between your application and XMediusFAX is executed under the context of the IUSR account. The XMediusFAX certificate that you have added to your trusted certificates applies to your user account, not to the IUSR account. When you replace IUSR with your account, it works, since it gets your list of trusted certificates.
There may be a few solutions available to you, depending on your needs. For example:
You could setup a local account (on the IIS server), select it for the anonymous user identity, login with that account and add the
XMediusFAX certificate to the trusted certificates of this account
You could have your XMediusFAX certificate signed by a trusted authority
You could implement a callback in your application to decide what to do with the certificate proposed by the XMediusFAX server
This last option may be a good one for you. I don't know the details of your application, but I would suggest that you take a look at RemoteCertificateValidationCallback to define a method to override the default certificate validation. In fact, if you don't really care about validating the server's identity, you can simply have your callback return true without doing any validation.
Hope this helps.
I'm using WCF services ensuring that UserName/Password must be provided for each request. I need use same service from many clients, but I need impersonate the call to access the appropriate resources for each client. When I call the service directly from the client there is no problem, because I use for each client a pair UserName/Password defined in theirs web.config. The problem came when I need to call a second Web service from a call to the first-one using the same identity. This second Web service requires UserName/Password, but I only know who is the caller (UserName) but not the password.
How I can impersonate this second call without knowing the password for the corresponding username?
EDIT: The app (Web App and Services) is running in a shared hosting environment where I can't use Windows Authentication to configure Kerberos for Delegation. I have defined a UserNameValidator to process on each call the pair UserName/Password against a custom SQLServer database. Moreover, the intended customers of this app will use it from Internet, without requiring a windows account, that is because I need a more flexible, SQL-based, authentication schema.
You need to look at using Kerberos to handle the passing of authentication onwards to other services from your first WCF service.
Have you taken a look at the declarative security options? The linked article by Juval Lowy includes an internet application scenario as well.
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.