Tag Info

Hot answers tagged

9

"Keyset does not exist" means you need to give your web application pool identity account access to your certificate. Do this in the Certificates Snap In.


5

Try to prefix the username with the membership provider info. It would look something like: web.EnsureUser("i:0#.f|membershiprovidername|username");


4

The big difference with claims based authentication is that you can easily (well it is still SharePoint) add other providers. For example you can add another provider and being able to sign in with your google account, live-id, linkedin account etc etc. Claims-based identity allows you to factor out the authentication logic from individual applications. ...


3

Members of AD groups cannot be viewed by SharePoint (without code). Therefore, when you check permissions, members of the group will show as having no rights. Here is an article discussing this: https://www.nothingbutsharepoint.com/sites/eusp/pages/active-directory-groups-vs--sharepoint-groups-for-user-management-a-dilemma.aspx


3

I had faced the similar issue when i was working with STS. The reason you get the error is because there is no trust being established between the Sharepoint and STS . If i am not wrong you might be getting the error at the below lines of code :) This is definitely a certificate issue. SecurityTokenService sts = new ...


3

Answering myself... I changed the script to perform these operations : Create the webapp with only Windows Auth Enable Claims authentication on the web app Add the remaining auth providers Extend the web app (passing all providers is working) Here the updated script : Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction 0 $winAp = ...


3

You can get claims through below code: var claimsPrincipal = Page.User as IClaimsPrincipal; if (claimsPrincipal != null) { IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity; var userClaims = claimsIdentity.Claims; } But if you want to add the claim at the time of ...


2

Whereas not answering your question exactly, it is very easy to get the "real" user object from a claim: SPClaimProviderManager claimManager = SPClaimProviderManager.Local; SPClaim claim = SPClaimProviderManager.Local.DecodeClaim(userLoginName); The important part being the DecodeClaim method. More information: Determining the original ...


2

The claims included in your token are only used to make authorization decisions inside of SharePoint. The custom claims provider provides claims augmentation (adding claims to your token) and claims lookup (people picker functionality). If you want to have user properties in the user profile service application, you still have to configure an import ...


2

_ Hi Bernd My draft post became over 2 pages, so I decided to cut some details, to get any replies at all. I have tried AllowNtlm = false, but for some reason I get the error message "The remote server did not satisfy the mutual authentication requirement." when I run. In IIS-Manager on the IIS-app I have only "Windows Authentication" and ...


2

You cannot configure the Forms based authentication if your web application is using Classic Mode Authentication


2

I must say the to my knowledge the migration to Claims should be done PRIOR to moving to SharePoint 2013, therefore in SharePoint 2010. In your case I'm wondering if the creation of the new user in User Information List isn't happening also because SID are not correctly copied. Also to check the differences - could take one "new" user and one "old" user ...


1

Your second guess is right, you have to write some logic to combine the two: merge both claims into a new claim, and give rights to this new claim. When you say "claims based authentication", which provider are you using? Windows or trusted IDP (typically ADFS)? If you're using ADFS, you could use the claims rule language in ADFS to add more claims to the ...


1

Well AFAIK (and as opposed to what Nikhil says), it is not possible to "merge" your FBA and STS users. For instance, the meaning of your FBA claim (i:0#.f|fba|user1) is this: The part before the first | is created by Sharepoint; you can't modify it. It depends on the provider type, the identity claim, and other stuff. Details about this encoding may be ...


1

About the mapping of "http://schemas.xmlsoap.org/.../name": The New-SPTrustedIdentityTokenIssuer cmdlet has a parameter "-IdentityClaim". The claim type you specify as an identity claim is "encoded" by Sharepoint into the "http://schemas.xmlsoap.org/.../name" claim. I don't think you must configure anything special here, just specify a claim sent by your ...


1

I just faced a very similar situation with a custom membership provider using claims in SP2013. After a lot of research and POC's, I could not get the Display Name in the people picker and the login name to be decoupled (basically, show a Display Name and generate the auth claims with a username or unique ID). Hopefully someone may chime in with a way to ...


1

After converting our 2010 farm to use Claims based authentication, out ArcGIS web services stopped working and our custom WCF web services no longer got the user credentials - I believe they function with anonymous access. It turns out that WCF web services need to be Claims Aware, which they are not. WCF Services used by Silverlight inside of SharePoint are ...


1

What I believe is the major difference is that with classic mode, you login directly, and if you need to be authenticated to a second server, it's not possible (you need to be logged in to this second server first -> new login screen). You will find that this is still often done but in that case the second connection is done under a different account (with ...


1

OK, I got this working (yay!), but man, it was tough. Basically, you need to force the token to be re-issued from the STS, which forces the claims augmentation code to run again. In my case, the business requirements were a little more complicated than that, because I needed to actually only have one of the claims possible, but that's outside the immediate ...


1

You state in the picture that the site collection at '/' doesn't even exitst. It should otherwise you're running unsupported unless every site collection is a host header site collection in the web application. See SharePoint 2010: Supportability of unprovisioned root site in a SharePoint web application


1

We finally found a solution, that consisted in changing the client library. We especially use the component described here : Support for NTLMv2 with Apache HttpClient using JCIFS. A sample code we used: QueryServiceStub queryServiceStub = new QueryServiceStub("SHARE_POINT_ASMX_URL"); List authPrefs = new ArrayList(1); authPrefs.add(AuthPolicy.NTLM); ...


1

There is no default way to search for users when using SAML authentication like with SiteMinder federation as SharePoint has no way to know what kind of directory you are using let alone performing lookups in it. The solution is to build a custom claims provider that plugs into SharePoint to provide additional services: claims augmentation and claims ...


1

Authentication is managed at the web application level only. It is not possible to have sites within the same web application use different authentication providers unless the entire application supports those providers. Maybe this article will help: http://msdn.microsoft.com/en-us/library/hh237665.aspx


1

I'm quiet mystified by how it works with UserY, it should always fail. When running with Claims without NTLM the only way to pass credentials is through a FedAuth cookie with your SharePoint STS SAML token. To get that token you have to call the SharePoint STS with a SAML token from your identityprovider (ADFS?). To get that token you have to call the ...


1

Someone actually built a web part extracting all claims from authenticated session http://allthingssharepoint.wordpress.com/2011/04/14/sharepoint-claims-web-part/ C:\Marius


1

IClaimsIdentity currentIdentity = System.Threading.Thread.CurrentPrincipal.Identity as IClaimsIdentity; //var userName = currentIdentity.Name; foreach (Claim claim in currentIdentity.Claims) { // claim }


1

I covered this at TechEd NA 2010: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/OSP306


1

everything remains as it is, you have a nice token of your claim that you can manage in your webpart, only that you will be forced to implement a custom provider claims to search for users or groups sull'ldap (people picker) and transform the result into a claim. I hope I explained myself visit this link: http://ldapcp.codeplex.com/


1

Can I assume when you say claims you actually mean Claims with Active Directory as user data store, where from your problem, right? If NOT, then you should have no issues as it all handled automatically by the claims - meaning that is all in your connection of the provider! If domainOne and domainTWO also are related to 2 AD domains, bi-directional trust ...


1

I'm not sure if this will provide the claims you are looking for, but hopefully will get you pointed in the right direction. In the code behind of the InfoPath form you can grab the current user, and from there determine the claims information. Try something like this in the On_load event SPClaimsAuthMembershipProvider claimsProvider = new ...



Only top voted, non community-wiki answers of a minimum length are eligible