I'm trying to use the object model of Sharepoint 2007 to make some changes over a list and read users and groups web settings...
For that I developed a Web Service (WCF) that is stored in the same web application as the sharepoint site in IIS.
Thats working.
I call inside the Web service
SPContext.Current.Web.CurrentUser
and thats user is not me, is "Sharepoint\System"
Why?
Other thing is that web I try to get all users using
SPContext.Current.Web.users
that only contain "Sharepoint\System", not the others.
WHY!!!
I give the full trust in the web.config and use the Ntlm authentication method.
It sounds to me like the issue is the account that your web service is running under. I would change the application pool that your web service is using and set the identity to a named account. Then, when you query the current user in Sharepoint, you should see the named account you identified in the application pool.
You did follow this guide?
http://blah.winsmarts.com/2008-9-Getting_SPContextCurrent_in_a_SharePoint_2007_WCF_Service.aspx
Related
i have a WCF service hosted in a managed windows service. This WCF service communicate with sharepoint through the client object model in order to create, delete and update the document. My WCF service use a netTCPBinding with message security and windows authentication.
I need to retrieve the identity of the caller to have the right user under the property 'create by' of the sharepoint document.
Without activating impersonation, the wcf run under an network application account (app_svc) and when i create a document, the 'create by' property have this value: 'app_svc'
When i use impersonation, the sharepoint give me a http 401 error. The WCF service and sharepoint are not on the same machine.
How i can do it? Note that i have no rights and no access on the Active Directory and the domain controller server.
Any Help would be appreciated.
i am not familiar with sharepoint. but when you're impersonating a client and try to forward the credentials to another machine, you have to ensure the following items:
the client gets authenticated through kerberos (set SPNs)
the sharepoint authenticates users though kerberos as well (set SPNs)
delegation to the target SPNs is activated on the technical domain account of the IIS application pool / service. If it is running under a local built-in account (network service, local system etc) delegation has to be activated on the computer account object in AD.
The whole scenario is also known as double-hopp scenario.
I cannot write a complete guide here. Best you google for impersonation, delegation and double-hop.
All the steps i mentioned require access to a AD domain controller.
I am deploying a .NET web service that connects to a database.
When a user within the domain connects to the webservice, I want their identity to be known by the webservice (since a subsequent call to the DB from the webservice uses a USER_ID() function to know which user is making the request).
The app pool that is running the web service is configured to run under a domain account that allows access to the database. When I query the web service, it is connecting as that account of the app pool, and not the user that is calling the web service.
I have tried various different impersonation configurations but I can't get the web service to interpret the caller's identity. Can anyone advise what I am doing wrong? Is the fact that my app pool that is running under a named account causing the problem? Should it be configured to something else?
No, it's not the app pool's problem. Impersonation has to be also set from configuration files which in fact, it's probably already been specified.
Now, you didn't mention what of service you are using. For the service to be aware of who is making the request through impersonation the service must be running in asp.net compatibility mode so it can participate in the asp.net pipeline. It's a pretty basic topic, but if you need more info, then refer to the MSDN article below
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute(v=vs.110).aspx
Leo
Hi We are building apps with sharepoint 2013. Currently we have them setup as two web applications with two separate domain names -
Wep App 1 - www.webapp1.com
Web App 2 - www.webapp2.com
We also have ASP.net membership role provider database which we use for authentication.
right now we want to implement Single Sign On for both the Web App. If i Authenticate with one web app and i try to navigate to the other web app i should not be asked to re-authenticate again.
How can i achieve this. i cannot use ADFS as we maintain a separate database with all the user info as a part of asp.net membership role provider.
Can someone guide me on how this can be achieved.
Appreciate your time.
You are right, the SP2007 model was a lot easier but not extensible.
Are these web applications on the same SharePoint farm?
The SharePoint STS can be shared across multiple web apps as long they live within the same farm. You can configure your webapps and the Sharepoint STS to use FBA with your custom membership/role provider.
We managed to implement a similar scenario but the webapp1 was living on Sharepoint 2010/2013 and the webapp2 was an standard ASP.NET app. The user logs in on webapp1 and the ticket was shared across to webapp2. The same scenario can be used to share tokens between Sharepoint web apps as long they live within the farm. (Your Sharepoint STS will internally talk to your membership/role provider however behind the scenes a FedAuth token will be created as your SP web apps only understand claims)
Hope this makes sense, if not let me know.
Gerardo Diaz
I have an MVC application using Windows Auth which consumes a Web Api service. Both are hosted within the same domain but sat on different servers (MVC is publicly accessible). Now lets suppose the Web Api service has a method "CreateFooBar" which requires that the user is in a particular AD group. At the MVC layer I can easily check that the user is indeed in the group, package up a JSON message and call "CreateFooBar". But how does the service perform such a check? How can I tell it which user has made the request?
Initial thought is just to add the userID to the JSON message and let the service method retrieve the details but this would allow someone to just pass in any userID they like so clearly this won't work. Can someone point me in the right direction please?
You should use something like Kerberos delegation.
The user will be authenticated in the MVC application using Kerberos then the Kerberos token will be passed to the Web API call.
We do that currently at work to pass credentials from an ASP.NET app to an Exchange Webserver. It works fine.
If you want more info check this KB: http://support.microsoft.com/kb/810572
You should look into what windows identity foundation can do for you. By setting up adfs in your environment and using claims you will address most the problems you are talking about.
you'll need the identity and access plugin for visual studio and you can test the idea out using a self hosted sts.
I have a webservice that's behind form's authentication. The site that hosts the service also serves as a site that requires a user to log in via the login page.
I have a second site that needs to be able to access the service that the first site hosts. However, when attempting to access the service, it fails because the service requires that the user is logged in.
The first site is on a seperate server than the second site, but both sites are on the same subnet. Thus far the only way I have found to have the second site access the first sites service is to allow all users via a web.config setting specific to the directory that hosts the services .ASMX file. This is not acceptable because it leaves the door wide open to anyone who knows the .ASMX file directory.
I have attempted to mix and match windows authentication and use impersonation to access the web service, but according to microsoft, you cannot mix and match authentication types, and through personal trial, you can indeed not.
I'm looking for any helpful tips to help me accomplish this goal at a minimal reconfiguration of my two sites.
Thanks,
George
I implemented the solution by adding custom security to the headers on the SOAP packets. This allowed me to mix and match my security at a minimal reconfiguration to the service.