SharePoint 2010 / SharePoint 2013 Fedauth and SessionID="True"

When you work with the fedauth cookie an issue might arise with the Size or information of the fedauth cookie. This could be the size of the cookie according to the information you put in to the claim or secondly the information itself in the cookie which might be sensitive (Privacy).

 Now you might be thinking, the fedauth isn't readable? Copy the information in the cookie in a basedecoder and you will be able to read the information that is put in the identifying claim... and some more stuff!

 According to a post published by Vittorio Bertocci you should be able to solve this by using the WIF functionality "IsSessionMode=True" and since SharePoint uses WIF..... (Windows Identity Foundation) We should be able to use this to in our SharePoint scenario's...




Wrong! We tried to get this to work (in various ways!) and quickly ran in to some strange situations wherein according to the post of Vittorio we should see it in action. 

It just didn't work, then our friend Google and bing gave us a few promising leads but they didn't resolve the issue either.  (Example:strackoverflow)

 So we opened up a case with MS, the end results from the PG is that they don't support it and build a custom mechanism against / next to WIF that changes the behavior in such a way that it isn't possible to use "IsSessionMode=True".

We explicitly asked if there was an unsupported method to get it to work, but alas a definite "No" is the anwser. (since both SharePoint 2010 and 2013 use the same WIF version / code, it's futile to put effort in it)

I hope this will save some of you a lot of time, which would else be wasted. 






Reacties

Een reactie posten

Populaire posts van deze blog

One ADFS to serve them all (Part I)!

Afbeelding
One ADFS to serve them all (part I)! The goal is to use a vanity URL host names that your site is using and to also use that same host name to resolve ADFS, without having you redirected back to the ADFS original service name (hostname + URL). Because for the end users this shouldn't look like anything else but the vanity domain they are already connected to. Thus how do we solve this? Follow this basic lab entry to get a feeling for the end solution. (I will post more about this subject in greater detail) The ADFS Limitation. The limitation I'm speaking of, in this case is the endpoint for SAML 2.0 / WS-Federation: "/adfs/ls"  (but as you can imagine it's pretty much every endpoint listed in ADFS) We connect with the 1 possible value set during installation for the federation service name: "your.host.name"  Which results in all endpoints only being accessibly under that federation service name.    Figure A: Federation service
Meer lezen

Microsoft Hub NVA configuration example.

Afbeelding
Microsoft Hub NVA configuration example. So in my previous post i gave a short description of implementing Microsoft Hub-Spoke model in IaaS. And i promised to publish some sample code you could use in CICD. Of course the main goal should be to get in to containers and such technologies but seeing as how slow large enterprises are willing to adopt and move to such technologies I'm guessing IaaS will be a standard for some time yet. So I'm going to give you a sketch of a private data center connection via express route (or a S2S VPN instead of the express route) to your azure subscription. And slowly start to explain a few basic configurations. The first overview:      So in this simple drawing you can see I've implemented a express route. I've not drawn a full blown resource drawing so you're bound to miss certain things like a circuit for instance but lets keep it simple. The green line is a express route configuration over whi
Meer lezen

RDS: Remote Desktop Gateway with NPS and Cross domain identities.

This post is about configuring a Remote Desktop Gateway in Resource Domain A while consuming the identities from Identity domain B. Setup: - NPS in Domain A  - RDG in domain A - MFA in Domain A Requirements a "TWO-WAY trust" with selective authentication (or wide if you have no security risks) It won't be possible to authenticate users from domain B in Domain A via the RDG until the computer account has gotten the permission "Allow to authenticate" on the domain controllers in Domain B. The simplest way to achieve this is by going to properties on the "Domain Controllers" OU in users and computers in domain B (RSAT tools) and going to the security Tab. (if you don't see the security tab in users and computers then make sure you've enabled "advanced features" under the view selection.) Then when you're in the security tab click the bottom advanced button. This will open the "Advanced Security Settings for Domain
Meer lezen