View Complete Post
I have setup the claims based environment with ADFS 2.0, everything is working fine but when i select my claims in the people picker its not validating weather the claim exists or not. its showing what ever i enter, as a result in the people picker page.
I want to check if the claim exists then only the claim should be shown as a result and resolved.
can anyone guide me how to start and where to make modifications. So that i can pick claims only which i have created or existing.
We have setup a test SharePoint environment on a single box. If we create a new classic authentication web application using NTLM the site works fine, and recognizes AD users correctly. Users can then login successfully. If we create a new claims based authentication
web application using NTLM all users receive an Access Denied error when trying to view the site. The application will recognize AD users when applying permissions in Central Admin's User Policy section, but none of those users are able to access the site.
If I turn on Fiddler Capture, the sites will work fine. Once I turn it off the sites no longer work and we are again presented with an Access Denied exception (or sometimes 403 Forbidden in Firefox and Chrome). I know that Fiddler create a local proxy so
I'm curious what that proxy is doing that allows claims based to work correctly.
Has anyone seen this before? Does this sound Firewall/Antivirus related? Client or server?
I am using next code to get SharePoint document content:
using (System.Net.WebClient objWebClient = new System.Net.WebClient())
objWebClient.Credentials = new System.Net.NetworkCredential("username", "password", "domain");
using (System.IO.BinaryReader file = new System.IO.BinaryReader(objWebClient.OpenRead("http://machine_name:10000/Shared%20Documents/some_file.txt")))
//Read file stream
I see that SQL Server 2008 R2 Reporting Services now supports
Claims Based Authentication in Sharepoint 2010, meaning that end users can authenticate with Sharepoint using Claims Based Authentication, and use the same security tokens to connect through to Reporting Services.
I assume that behind the scenes Sharepoint is using
Windows Identity Foundation (WIF - formerly codenamed "Geneva") to handle the authentication, and passing this on to Reporting Services.
I'm keen to use Windows Identity Foundation to authenticate with Reporting Services
without Sharepoint. We have an existing ASP.NET web application, and we'd like to call Reporting Services from that, passing on the Windows Identity Foundation credentials of the user logged into our web application.
I've done some work on setting up a custom security extension using Forms Authentication (based on the
sample), but am not sure how to proceed from there.
Google/Bing hasn't been helpful. Can you please point me to some guidance on how to set up Windows Identity Foundation authentication for Reporting Services?<
I'm planning to use CBA to do authentication and authorization to a document library. For example, if you have the claim type 'location' equal to 'London' then you are granted access to a folder. Simple, and it works great from the out-of-the-box
web browser interface.
The question is, can the Web Services interfaces also accept a signed SAML token and use those attribute to do authentication and authorization? I would prefer to use the CMIS interface where possible. I understand that the web services
are based on WCF, which leads me to believe I can just modify the web.config to add in WCF directives for ws2007HttpBinding->security->message, but will the SP web services code respond by using the identity in the message?
What I have noticed so far, is that the CMIS interface has directives for only impersonation only. Since CBA identities do not map to windows accounts, I thinking I'm barking up the wrong tree. I'm not dead set on CMIS, so if there are other
web services available to do CBA, I'm all ears.
There's not a lot of practical material on this, and I'm currently working on a PoC to acheive this goal. Any help would be greatly appreciated.
Does anybody know of a guide or reference for setting up hosting in a multi tenant where authentication happens in claims based mode?
We have a setup where our clients are hosted on a single web application under different site collections. And we use forms authentication where user of a particular site collection gets authentication using the respective database. We now want to use claims
based authentication and out-of-the-box multi-tenancy of SP 2010. We can setup site collections and site groups, but how do we implement claims based authentication in an env like this?
We recently upgraded our MOSS Forms based web application to SharePoint 2010. In MOSS, we had a custom login page and in here we would create a persistent cookie named .ASPXAuth (valid for 365 days) if the user selected remember me while logging
in. If remember me was not selected, then we would a normal session based cookie which would have a timeout period as specified in the web.config.
With Claims based applications, this technique has considerably changed. Because of the STS service which is now responsible for creating the tokens (and automatically creates a cookie called
FedAuth with a specified lifetime as per the STS settings, how do I replicate the MOSS 2007 custom login page functionaliy ?
Any code examples will be helpful....My login page functionaliy is simillar to the one discussed in the below link:
I have configured one of my SharePoint sites default zone with windows authentication and claims authentication. I am able to access the site properly with windows authentication. But, when I am accessing the site with claims, I am getting Http 500 error.
When I captured the http headers, I see below information.
POST / HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate