Operationcontext current servicesecuritycontext windowsidentity groups

The code is straightforward, so I do not have a lot of commentary to add. In this case, the "entity" parameter being used in the DecodeUserIdentifierClaim method is passed in as part of my override of the FillClaimsForEntity method that is, augmenting claims in my custom claims provider. The method shown here should work anywhere in a custom claims provider.

I have been asked this question a couple of times before, which is why I want to be able to programmatically find out what claims providers are being used with my web application. The method that I am demonstrating reveals the SPTrustedIdentityTokenIssuer value and custom claims providers that are not enabled by default because if a claims provider is enabled by default, the claims provider is used everywhere.

The first thing to understand is, if you are wondering what is enabled for a web application, you are thinking about it incorrectly and this is probably why you have had a hard time finding this information.

Your claims providers are going to be applied at the zone level, not the web-application level. With that information, you can get the SPIisSettings information for the zone, which is where most of the interesting information resides. After I have the zone information, I can get both the authentication providers and the claims providers for that zone. Fortunately, that is not too hard either. For completeness, following is the entire code block. For each SPTrustedIdentityTokenIssuer object, I create a string with the name of the trusted login provider and the URL to which you would get redirected to authenticate when using that trusted login provider.

A fairly constant hurdle when doing claims augmentation in SharePoint has been trying to figure out what claims a user has when your custom claims provider is invoked to do claims augmentation. The claims you want to augment for a person may depend on the value of other claims that the user has.

For example, if the person belongs to the role "Domain Administrator", add the role claim "Uber User", otherwise add the claim "Standard User". One of the underlying problems in trying to get to this information outside the parameters provided when your claims provider is invoked for augmentation is that you do not have any access to an HttpContext object to look at the collection of claims.

Israel correctly figured this out and figured out the alternative, which is using the OperationContext object. So what is the OperationContext object? In a nutshell, what we care about is that the OperationContext object enables you to access incoming message headers and properties. So, how does this help us? Well, when your custom claims provider is invoked for augmentation, you can get to this incoming message information. The following XML shows what the incoming message information looks like.

Now that we have a chunk of XML with our claims embedded inside, it is simple to unwrap them and use them during augmentation. The following code shows how to do that. That is pretty much it. The code is straightforward and verbosely commented out. The primary identity is obtained from the credentials used to authenticate the current user. If the credential is an X. The subject name is separated from the thumbprint with a semicolon and a space.

If the subject field of the certificate is null , the primary identity includes just a semicolon, a space, and the thumbprint. When a duplex message exchange pattern is used with Kerberos direct authentication, this property becomes empty on the callback and the claimset is also empty.

This does not happen when SspiNegotiated is used instead of Kerberos. The Kerberos Requester Token is used only on the client to represent the service. Return the current AuthorizationContext class. Use the Current property to return the current service security context, then return the AuthorizationContext using the AuthorizationContext property. The following example prints the values of the WindowsIdentity and PrimaryIdentity properties of the current security context and the ClaimType property, the resource value of the claim, and the Right property of every claim in the current security context.

Skip to main content. Learn more. Asked 11 years, 8 months ago. Active 9 years, 8 months ago. Viewed 7k times. Can anyone shed light on how I could set the PrimaryIdentity field? Will Will 1, 15 15 silver badges 26 26 bronze badges. Add a comment. Active Oldest Votes. ContainsKey "Identities"? Community Bot 1 1 1 silver badge. Nabheet Nabheet 1, 1 1 gold badge 12 12 silver badges 20 20 bronze badges. While your answer is definitely useful, it raises even more questions.

Where does the "Identities" magic string come from? Why would a list with more than one item "confuse" WCF? Most importantly, where did you get all this information from since there is nothing related to this in the official documentation?