I have a custom WCF web-service confugured with windows authentication and a WPF client application that needs to call the former. The service checks the username and pull some specific data from a database. So I have to call the service using credentials of the user running the application.
The problem is my service is hosted under another site with windows authentication and users can authenticate there with another accounts. Windows (or IE?) caches last accout used and then my client app uses it too!
Example:
I enter the website under "MYDOMAIN\AdminUser"
I run following code (from the client app, it's not web code)
var client = new TestServiceClient();
var currentUser = WindowsIdentity.GetCurrent(); // just informative field nothing more, i don't use it anyhow
// currentUser.Name = "MYDOMAIN\\MyUserName" - it's current value, i'm not trying to set it
client.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
var data = client.GetTestData();
Service gets called by "MYDOMAIN\AdminUser"..
I know I can create NetworkCredential with name and password but I then will have to store it somewhere, encript it and so on..
To clarify the problem: client process running under one account calls the service under another account by itself, just becouse windows supplies the call with another credentials under the hood.
Related
I have setup a SharePoint dev environment and managed to get a provider hosted app working with Certs etc (High Security)
This is all on-premise and we won't have a connection to ACS (now, I may have miss understood ACS, I presume its azure based and servers need to talk to server outside of the server room :) ).
My problem is:
The SharePoint site will not be using Windows Auth, we will be using a login form which will read details from another store.
If I review the code that VS generates I can see that it expects a Windows identity.
Can this be done? I would have expected my provider app not to need any auth as its hosted via SharePoint, it gets the claim from SharePoint so why does it need a Windows Identity as well as the SharePoint Claims.
As you said : The SharePoint site will not be using Windows Auth, we will be using a login form which will read details from another store.
Ans : You are talking about Form based authentication.
If I review the code that VS generates I can see that it expects a Windows identity.
Ans : You are correct. VS generates the code that expects windows identity [For dev environments]. You need to write separate function to get clientcontext for FBA using SharePointContextProvider class.
Context can be :CreateAppOnlyClientContextForSPHost(),CreateUserClientContextForSPHost()
I would have expected my provider app not to need any auth as its hosted via SharePoint
Ans : You can make IIS site [Hosting your provider hosted apps] to allow annonymous authentication.
You can get access token with this code.
var contextTokenString = TokenHelper.GetContextTokenFromRequest(Page.Request);
var appWeb = new Uri(clientContext.Web.Url);
if (contextTokenString != null)
{
SharePointContextToken contextToken =
TokenHelper.ReadAndValidateContextToken(contextTokenString, Request.Url.Authority);
string accessToken =
TokenHelper.GetAccessToken(contextToken, appWeb.Authority).AccessToken;
}
Get current user :-
// Get current context to get load siteurl
var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);
string webUrl =spContext.SPHostUrl.ToString();
//using (var clientContext = spContext.CreateUserClientContextForSPHost())
using (ClientContext clientContext = new ClientContext(webUrl))
{
clientContext.AuthenticationMode = ClientAuthenticationMode.FormsAuthentication;
clientContext.FormsAuthenticationLoginInfo = new FormsAuthenticationLoginInfo(uName, pswd);
Web web = clientContext.Web;
clientContext.Load(web);
clientContext.ExecuteQuery();
// Load SP user from login name found from httpcontext
string currentSPUser = string.Concat("<<<FBADomainPrefix>>>",User.Identity.Name);
var currentUser = clientContext.Web.EnsureUser(currentSPUser);
clientContext.Load(currentUser);
clientContext.ExecuteQuery();
}
I have a Web API application which I'm protecting with Windows Authentication (locally, it'll translate to AD in the production environment). I just started adding features that rely on authentication and/or getting properties of the current user, and I immediately fell on a road block: the testing server doesn't seem able to authenticate.
How can I make the following test code send an authenticated request using Windows Authentication?
using (var server = Microsoft.Owin.Testing.TestServer.Create(MyApp.Startup.Configure)) {
var response = server.HttpClient.GetAsync(url).Result;
// Assert things about the response
}
I have got an ASP.NET MVC 4 Intranet Application.
The application uses the windows authentication for authenticating users.
I can get the Username with User.Identity.Name. This contain the domain name and username (MyDomain\Username).
I now want to add an appointment to the users calender via the Exchange Web Service API.
I can do this like the following:
var service = new ExchangeService(ExchangeVersion.Exchange2010_SP2);
service.Credentials = new WebCredentials(Settings.MyAccount, Settings.MyPassword);
service.Url = new Uri(Settings.ExchangeServer);
var appointment = new Microsoft.Exchange.WebServices.Data.Appointment(service);
appointment.Subject = setAppointmentDto.Title;
appointment.Body = setAppointmentDto.Message;
appointment.Location = setAppointmentDto.Location;
...
appointment.Save(SendInvitationsMode.SendToAllAndSaveCopy);
This adds an appointment for the user specified in the credentials.
I do not have the password for the currently logged in user.
Since I am using Windows Authentication (Active Directory Account), is there a way to somehow use this authentication information to use the Exchange Web service with the account of the user who uses the web application?
Because of security it is not possible to retrieve the user's password from Active Directory.
Is there another way of doing this?
Is it possible to create an appointment for another user as the user who uses the service?
Greetings
Alexander
You have two options for setting the Credentials.
// Connect by using the default credentials of the authenticated user.
service.UseDefaultCredentials = true;
or
// Connect by using the credentials of user1 at contoso.com.
service.Credentials = new WebCredentials("user1#contoso.com", "password");
Source for the above and full info is here http://msdn.microsoft.com/EN-US/library/office/ff597939(v=exchg.80).aspx
Microsoft also recommends using Autodiscover to set the URL endpoint
// Use Autodiscover to set the URL endpoint.
service.AutodiscoverUrl("user1#contoso.com");
If you wanted to create an appointment for another user you would use
appointment.RequiredAttendees.Add("user2#contoso.com");
or
appointment.OptionalAttendees.Add("user3#contoso.com");
Depending if they were required or optional.
However, this changes the appointment to a meeting. The meeting request is just an appointment with attendees.
I have an MVC4 Web Application on Web Server A that is consuming the Dynamics CRM Web Service using the OrganizationServiceProxy, which is on Web Server B. The MVC4 application is setup with ASP .NET Impersonation and Windows Authentication enabled. When I call the WhoAmI I get an error:
'The caller was not authenticated by the service.'
Now if I move the MVC4 Application to Web Server B (same as CRM) with the same Authentication as it had on Web Server A it calls WhoAmI without an exception.
Here is the code being used to connect to the server.
string serviceURL = ConfigurationManager.AppSettings["CRMROOTURL"].ToString() + "XRMServices/2011/Organization.svc";
this.CRMService = GetCRMService(serviceURL);
private OrganizationServiceProxy GetCRMService(string serviceURL)
{
ClientCredentials credentials = new ClientCredentials();
credentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
OrganizationServiceProxy client
= new OrganizationServiceProxy(new Uri(serviceURL), null, credentials, null);
return client;
}
Here is a screenshot of the authentication on the IIS Web Site.
Per the correct answer I just wanted to provide some snippets to help anyone else.
string loggedUser = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
ClientCredentials credentials = new ClientCredentials();
credentials.Windows.ClientCredential = new NetworkCredential(username, password, domain);
OrganizationServiceProxy client
= new OrganizationServiceProxy(new Uri(serviceURL), null, credentials, null);
client.ClientCredentials.Windows.ClientCredential = credentials.Windows.ClientCredential;
// -- Retrieve the user.
QueryExpression expression = new QueryExpression
{
EntityName = "systemuser",
ColumnSet = new ColumnSet("systemuserid")
};
expression.Criteria.AddCondition("domainname", ConditionOperator.Equal, loggedUser);
EntityCollection ec = client.RetrieveMultiple(expression);
if (ec.Entities.Count > 0)
{
// -- Impersonate the logged in user.
client.CallerId = ec.Entities[0].Id;
}
Thanks!
Unless you explicitly state otherwise (and without any code to see how you are creating your OrganizationServiceProxy), on premise OrganizationServiceProxies will use the current AD account (of the service account, not the user's specific account) to connect to CRM. I'm guessing that the App pool you're running on Server A isn't a CRM user, and the one on Server B is. If so, either change Server A's user to be the same user as Server B, or make the Server A's user a user in CRM.
Edit
You're using the default network credentials to connect to CRM. This mean that no matter what IIS authentication you are using, you will connect to CRM as the App Pool User Account. This works as long as the App Pool user is a CRM user, but is probably not what you want.
You can set the network credential manually using this method:
creds.Windows.ClientCredential = new System.Net.NetworkCredential("UserId", "Password", "DomainName");
Then get the ASP.Net User's domain name and use impersonation to connect to CRM to ensure that all of the security for that individual is correctly applied.
Something stupid - be careful you aren't escaping your user name!
creds.Windows.ClientCredential = new NetworkCredential("domain\user", "PASSWORD");
Notice that the \u is an escape sequence - you need to type "domain\user".
I've created a WCF webservice, that can dynamically call other webservices/db connections with DLL's loaded with .LoadFile('from assembly'). Inside one of these assemblies, another webservice is called dynamically with a passed in network credential as follows:
WebClient client = new WebClient();
client.Credentials = this.networkCredential; //This credential is passed in
RequestStream requestStream = client.OpenRead(this.url);
//rest of code. The .OpenRead is giving 401 error (not authorized).
When I do this in debug mode from a test console application and creating the network credentials as follows:
NetworkCredential networkCredential = new NetworkCredential(<userid>,<password>,<domain>);
this works fine.
The failing code is providing networkcredentials as follows
System.Net.NetworkCredential networkCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
Any help would be greatly appreciated.
Unless you are using impersonation, DefaultNetworkCredentials attempts to use the credentials of the process running your ASP.NET website, not the credentials of the user accessing your site. In order to use the credentials of the user, you should wrap your call to the web services in an impersonation context.
var impersonationContext = HttpContext.Current.Request.User.Identity.Impersonate();
if(impersonationContext != null)
{
//call your webservice here. DefaultNetworkCredentials will be what you expect.
impersonationContext.Undo();
}
There are, of course, conditions. The user must be authenticated (can't be an anonymous user, unless the anonymous user also has access to your web service). Also, the code above is just an example - in production code there are quite a few other things to consider. Here is an msdn article that should help get you started.
FYI, the reason it works in development is most likely because your development server process runs as you, and since you have access to the web service, it succeeds.