SharePoint 2016 and the first class citizen
I installed my first SharePoint 2016 farm yesterday. I went for SP 2016 Release Candidate (obviously), running on top of Win 2016 Technical Preview 4 and SQL Server 2016 Community Technology Preview 3.3. I was mostly happy with the installation experience, and although there were a few rough edges here and there, it went a lot more smoothly than I expected for a combo of three preview products.I noticed some changes in the configuration process (MinRoles), but otherwise, everything looked very familiar. Much more familiar in fact than almost exactly 3 years ago with SharePoint 2013. I did not expect anything major though, so I was not disappointed.
There was however one feature I was eagerly looking forward to: SAML authentication (or Trusted identity provider authentication, as it is called in SharePoint, which is actually SAML-token based authentication using SAML 1.1 and WS-Federation, but don't let this confuse you too much).
Back at Ignite 2015, Bill Baer promised "SAML authentication becomes a first class citizen in SharePoint 2016" (don't take my word for it, he says it right at 11:30min on this video from Ignite: https://channel9.msdn.com/Events/Ignite/2015/BRK2188) and he goes on to say "we chose SAML authentication as a default". I was very excited to hear this.
I really like the concept of SAML authentication, and have implemented it in several real-world scenarios. The thing I like most about SAML, is the possibility to extend the claims ticket of a user with additional claims. You could, for example, add the users nationality to the claims ticket, and add a nationality claim (e.g. "German") to a user group in a SharePoint site. The beauty of this solution is, that SharePoint respects these claims, and will treat them just like traditional AD group based or user based permissions.
If you are not familiar with this concept, I highly recommend reading a series of blog posts on this topic by Steve Peschka (see the end of this post for links).
Is the people picker broken?
The problem? There is no out of the box possibility to do proper name resolution when using SAML authentication. I found a post titled "Is the people picker broken" when I was once again doing some research on this topic (http://www.sptechcon.com/news/is-the-people-picker-broken) and a suggestion on uservoice.com to "Ship SharePoint Server 2016 with a SAML Claims-aware People Picker" (https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/8216679-ship-sharepoint-server-2016-with-a-saml-claims-awa).Yes, it is broken.
You can, if you really want to, install a 3rd party claims provider (often but not quite correctly referred to as "people picker") or even write your own. This does sound promising, however, there is one major flaw with this.The claims provider must inherit the SPClaimProvider class...
... and the SPClaimProvider class contains both claim augmentation and searching and resolving claims. This means, from a technical point of view, you are adding a component which will interfere with two processes in your SharePoint farm:
- The log-in process (claims augmentation)
- Selecting users (or claims) in the people picker (search and resolve)
Now I don't know about you, but most of the environments I've seen can go for a few hours or days without being able to use the people picker. Users will cry, and there will be angry emails, but everybody will be fine in the end. The same is not true for logging in. Most environments I've seen can definitely NOT go without the ability for users to authenticate for several hours.
When you install a claims provider, you are adding a single point of failure to your farm, which might break the whole authentication process, even though you only wanted to make it easier for your users to use the people picker. And we all know, authentication not working is a synonym for "EMERGENCY!!! Cannot access SharePoint!!!1". And I've seen this happening first hand.
If SAML is a first class citizen in SharePoint 2016...
... then I'd like to see the search and resolve functionality separated from the claims augmentation process. I really don't like the idea of having to mess with both, if I "only" want to provide search and resolve to users.
I have tried a few third party claim provider solutions, but I'm not happy with any of them. I also started implementing my own, but quickly gave up, once I noticed how badly I could break the authentication process.
I have tried a few third party claim provider solutions, but I'm not happy with any of them. I also started implementing my own, but quickly gave up, once I noticed how badly I could break the authentication process.
My suggestion?
Most organizations I see use both SharePoint Online and SharePoint on-prem, in a "hybrid" scenario. The level of integration between the Online and on-prem flavors varies, but I'll call it hybrid anyway. For this case, why not provide the possibility to do people picking against the Azure AD directory the organization is using with O365? People picking might get a consistent experience throughout Online and on-prem sites, and a very large portion of cases would be covered. Do this, and I'll believe SAML is a first class citizen in SharePoint 2016.Further reading on the SAML with SharePoint topic:
Steve Peschka on SAML and custom claims providers:Part 1: https://samlman.wordpress.com/2015/02/28/writing-a-custom-claims-provider-for-sharepoint-2010-part-1-claims-augmentation-and-registering-your-provider/
Part 2: https://samlman.wordpress.com/2015/02/28/writing-a-custom-claims-provider-for-sharepoint-2010-part-2-adding-support-for-hierarchy-nodes/
Part 3: https://samlman.wordpress.com/2015/02/28/writing-a-custom-claims-provider-for-sharepoint-2010-part-3-searching-claims/
Part 4: https://samlman.wordpress.com/2015/02/28/writing-a-custom-claims-provider-for-sharepoint-2010-part-4-supporting-resolve-name/
Kirk Evans on fixing the people picker:
https://blogs.msdn.microsoft.com/kaevans/2013/05/26/fixing-people-picker-for-saml-claims-users-using-ldap/
No comments:
Post a Comment