Showing posts with label Claims. Show all posts
Showing posts with label Claims. Show all posts

Sunday 11 December 2016

Extranet Authentication Options for SharePoint 2013

Overview: Most large enterprises using SharePoint have implement Extranet solutions and these vary in complexity greatly.  Many implementation I have seen have morphed into bazaar solutions generally due to the tactical solutions implemented over time and were not caused by poor architecture.  It is the nature of these projects to get something out and with the rapid change in authentication over the past 5 years tons of business have landed in complex scenarios.

Office 365 has grown quickly and using Office 365 is generally a good idea however a lot of organisations still are resistant due to a variety of concerns such as regulatory compliance and trust.  Microsoft is definitely removing these barriers and I'd lean towards hosting the SharePoint Extranet in the cloud in the majority of situations.  The biggest barriers to moving to the cloud are Executive level buy in followed by senior IT folks that are bias to sticking to what they knew 10 years ago.   So a lot of the change is around education and providing a clear road-map.  The biggest technical hurdle will be around identify management.

Pretty much every organisation I deal with used Active Directory and then you may have a Federation Service normally ADFS.  You may have you external users in the same AD, a dedicate DMZ AD, or any other user directory including SQL or other LDAP provider.

Using Office 365/SharePoint Online I need to get both my internal and external users to be work with Office 365 and depending on the client setup I need to work thru both scenarios and think about the ramifications.

Note:  Ramifications are: resetting user passwords, does search work for all users and where does the data reside.

Possible Options:
  • AzureAD - Azures ACS for user accounts
  • Federated Identifies - use ADFS and build trust with ACS, identity and password is under our company control
  • AD sync to AzureAD - Think DirSyng, tooling is ADConnect
On an on-prem. SharePoint farm, the following Authentication methods are supported at the Web Application Level:

  1. Classic (Windows (Basic/NTLM/Kerberos)), 
  2. CBA - Claims Based Authentication backed by either Windows Claims (Windows (Basic/NTLM/Kerberos)) or SAML Claims (ADFS or SiteMinder or Ping or ThinkTexture, ....)
  3. FBA - Forms Based Authentication, and 
  4. Anonymous (none)

Notes:
http://www.sharepointeurope.com/blog/2015/10/identity-management-in-a-saas-based-world

Thursday 19 March 2015

Identity Providers for SharePoint

Overview:  I have worked with and evaluated a couple of Services and Federation Server products.  Here is an old pot of setting up claims, at the bottom I have some thoughts on different services/server products.
Background: SAML and WS-Federation protocols are standard Single Sign-On protocols, the following version exist:
  • SAML 1.0, SAML 1.1, SAML 2.0
  • WS-Federation
Security Assertion Markup Language (SAML) is an XML-based protocol for exchanging authentication and authorization data between security domains.
SAML enables web-based authentication scenarios including cross-domain single sign-on (SSO).  SAML is a token representing a principal that normally represents a user but can represent an app.
  
Other terms to understand:
  • Identity provider (IdP) think ADFS/Azure ACS,
  • Service provider (SP) is the SAML consumer in our context this is SharePoint but this can be an MVC app.
  • Realm
OOTB SP2010 and SP2013 support SAML1.1 not SAML2.0, you can write custom code or use a Federation Server like ADFS to convert the SAML2.0 so it will work with SP.
Identity Provider (IdP) Products:
  1. Microsoft ADFS
  2. Ping Federate
  3. ThinkTexture Identity Server
  4. CA-SiteMinder
  5. IBM Tivoli (CAM)
  6. Oracle Access Manager
  7. ComponentSpace
  8. Shibboleth
  9. RSA Federated Identity Manager
  10. Entrust GetAccess
 IdP Services:
  1. Azure Active Directory
  2. LiveId
  3. Google
  4. Facebook
  5. LinkedIn
  6. Yahoo
This list is in no way exhaustive, pls post if you feel I am missing any providers.

Tuesday 19 August 2014

SharePoint 2013 on-prem using Windows Live Id via Azure ACS

Overview:  I have a pretty simple requirement to allow users to register on my customers public SharePoint 2013 web sites.  I have setup custom providers and thought ACS was going to make me a hero at my client.  The whole experience is terrible and I can't see why anyone would use the default of LiveId via ACS due to the implementation.

Opinion: I hate the way ACS works with Windows Live Id, it is so bad I can't see a scenario when a client would use it.

Anyway, I have SP2013 SP1 on-prem and I want to hook at ACS allowing customer to register on the site and get elevate permissions on the site.  I'd like them to use multiple 3rd party authentication providers such as Facebook, Windows Live Id, LinkedIn and Google.  In my PoC I decide to simply use Live Id as it is the default on ACS and as both services are Microsoft owned it must be the easiest. 

I worked thru Wictor Wilem's post series and as usual Wictor has provide a great resource.  I had to make minor adjustments to get it to work for me on SP2013 but overall, Wictors series of posts is a good place to start.

The 1st issue I got was when logging in using Windows Live ID, I was continuously redirect back to the /_login/default.aspx page.

After bashing my head trying to figure out what the issue was I realised in Wictor's common issues post in the series, he mentioned the claims mapping/rule needs to be adjusted for Live ID authentication. 

I now was getting an access denied, which at least told me the claim was hooking up.

The next issue was now I was getting the message you are not authorised "Sorry, this site hasn't been shared with you."

Give all authenticated users access to the site as shown below.

Once you login you will notice a horrible looking user that is logged in.   You can assign permissions using the "Friendly Username".


Common public Federation (IdP) Identifcation provides are:
  • LiveId (MS - not where you would expect the MS offering to be)
  • Google (constantly changing - easy hookup)
  • FaceBook
  • LinkedIn
Common Enterprise IdP Servers/Services are:
  • Microsoft ADFS (best default option for greenfield SP)
  • PingFederate (pretty expensive but a comprehensive solution, use if already in place or the advanced features really suit the business at an enterprise level)
  • ThinkTextures IdentityServer (Great for customisation, difficult support but for the hardcore tecky type organisation a good option)
  • CA-SiteMinder (Good product, used in enterprises and hooks up well to SP.  Has a large set of tools and options).  Update: 19-Nov-2015, seen another large implementation of SiteMinder, it has expensive add-in modules and extremely problematic.  SP agent needs AD groups.
  • RSA Federated Identity Manager (No experience)
  • Entrust GetAccess (No Experience)
  • IBM Tivoli (CAM) (Had a hard time with this a few years back)
  • ComponentSpace (Good for .NET customisations, not a large Federation service Server)

Wednesday 23 May 2012

Retrieving Claims Values in SP2010

Problem:  Developer wants to retrieve values from the users claim to send an email.

Intial Hypothesis:  Create a web part to demonstrate the code that displays all the claim values.  Pull out the claim values such as the UPN in my case and send an email to the current user based on the upn value.  The upn in my dev machine is the users email address but it obviously depends on how you claims are setup.

Resolution:  Create a new SharePoint project and add a web part.  Then add the code as shown below.
Updated 28 May 2012 - Format of claims post
Example from ADFS2.0 connecting to AD:  "i:0ǽ.t|mkting|testuser"

Thursday 9 February 2012

Authentication Evaluator

There are articles on building web parts to display claims on a page which can be a useful tool.
http://blogs.pointbridge.com/Blogs/nielsen_travis/Pages/Post.aspx?_ID=32
http://jopx.blogspot.com/2010/09/building-claims-viewer-webpart-for.html

Below I have added my own, nothing new or exciting but part of my discovery on CBA:
The code to display the current users Claim is shown below:
There is a codeplex project that provides a web part that display the Claim token.  As the code is so short I'd rater write it myself.

Monday 12 September 2011

CBA for Developement

Problem: Claims Base Authentication (CBA) requires swapping certificates with each machine that will use CBA on a development domain, if you have 20 dev machines you will need to swap certs with ADFS and 20 developer machines. 

Note: This post assumes all dev machines are on a single domain however several approaches will work on a standalone machine however.  If ADFS is present on the local dev use it for CBA in your development environment.

Initial Hypothesis:
If your VM's are all on the same domain you can always use classic mode authentication and test the CBA on a build server.  This does not make the dev env mimic the test, QA & production servers that are using claims for authentication.
 
Resolution:You could setup your own STS server/Service (feeding off SQL or LDAP) or use the WIF toolkit to create a claims service.
Or use SelfSTS tool to generate claims that SharePoint can consume.

More info:
Setting up and testing your own STS Service
http://msdn.microsoft.com/en-us/library/ff955607.aspx
http://blogs.msdn.com/b/sharepointdev/archive/2011/09/12/claims-architecture-for-sharepoint-2010-developers.aspx
http://archive.msdn.microsoft.com/SelfSTS/
Simple channel 9 Video explain CBA & WIF

Monday 21 February 2011

Mapping internal users (LDAP) to the cloud

Overview: Steve Plank has a great video on "How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud". 

To get your internal ADFS users to authenticate in the Microsoft cloud (Azure and Office 365), you do need ADFS 2.0.  The claims based authentication that can be setup in SharePoint 2010 is how Office 365 and AZURE will authenticate AD users. 

You users will access SP2010/MS Online365/AZURE Web application using their browser.  The end application sends the browser a response redirecting them to the MS Federation Gateway (MFG)/App Fabric/STS web service (SP2010 on site editions), this in turn passes the users browser onto ADFS.

ADFS generates the user a SAML token and the are redirected to the MFG, MFG in turn generates it's own SAML token containing it's claims and the browser is redirect back to the originally requested web application.

For a user trying to access SharePoint Online from their internal network, you can see the user makes several requests to different points along the chain however the key result being the user get securely authenticated against you internal Active Directory (AD).
Steve Planks video is easier to follow than this post but it's worth understanding the process as it applies to Azure, SharePoint claims based authentication and Office 365.  This coupled with custom LDAP providers results in a consistent manner to handle authentication in the cloud using you internal LDAP directory.

Below is an animation describing the process whereby a user is authenticated on their internal network and then they use SharePoint Online (Office 365).
More Info:
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx?wa=wsignin1.0

Settingup ADFS for SharePoint Reference:
 

Saturday 27 November 2010

Change to session cookies for Claims Based Authentication

When you log into SharePoint using Claims Based Authentication, a cookie is written/persisted to ​disk (FedAuth) to persist your session, which prevents you having to be authenticated each time you open a new browser or re-boot.  So using a FedAuth cookie allows the browser to close and re-open windows as long as the FedAuth cookie has not expired.  For ADFS, FedAuth cookie expiry is by default set to expire 10 minute earlier than the SAML token.

You can change the cookie to be session based by running this PowerShell script:

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

You can revert back to a disk based cookie (default) by running this:

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

Show cookies on a local machine for Internet Explorer

IE > Internet Options> General > Browser history "Settings" > Temporary Internet Files "View files".

Update 2016/03/10
Tip:  I wanted to examine a cookie to check the user being authenticate, and I opened the cookie using a base64 online decoder https://www.base64decode.org/




Update: 2016/11/23
IE Developer tool bar and Fiddler are great and easy to use and pretty feature rich but lately I have been using Chromes Developer toolbar press "Ctrl" + "Shift" + "i".



Thursday 18 November 2010

Custom Claims Membership Provider

Problem: We have written a custom claims membership provider, it works in development however if fails in the UAT environment.  The Membership provider goes to an LDAP directory (IBM TAM).

Initial Hypothesis: After checking the configuration was correct, I looked at the logs that were informing me that the provider was not returning results.  We can't use wireshark on the UAT environment to verify the call is being made to the LDAP directory.  And the error message is a generic failure message.

Resolution: Use Telnet to check that the WFE/WebService/STS/SharePoint token service can speak to the LDAP directory.
cmd>Telnet 192.168.1.101 389

The Claims web service cannot contact the LDAP directory, most likely cause is the firewall or the windows firewall.  Add a rule to the firewall to allow traffic on port 389.

Friday 22 October 2010

Extranet user access options - Farm architecture design considerations

Problem: What is the best approach for an extranet?

Hypothesis:
You are implement SharePoint 2010 and you need users to have remote access, the 2 key technology impact areas are:
• Authentication to SharePoint 2010; and
• Remote access mechanism (External users).
I will deal with each question separately for simplicity.

Authentication
SharePoint 2010 has 2 mechanisms for authentication: classic (MOSS approach) and claims based. I would almost always recommend using Claims based authentication as this allows you to hook into any credential provider such as LDAP, AD, SQL or a custom provider. For example a recent project involved authentication from Active Directory & an IBM LDAP provider, this was relatively easy to do using claims based authentication.  If you have a custom Single Sign-On (SSO) solution you can write your own claims provider.
Remote Access
The answer for where to deploy SharePoint is … “It depends on what you have currently, your licencing and security requirements.”

Option 1
You can put SharePoint in your DMZ (public area) and use a reverse proxy and allow users access to you SharePoint farm. You will probably want to use SSL between the external end users and the reverse proxy.  The traffic between the SharePoint Farm the proxy won’t be under SSL. This approach is good for easy access, high performance and easy setup. This approach is not as secure as getting users to login to your network using VPN access. The advantage is you merely need SSL setup (my preference is firewall SSL termination i.e BlueCoat, most hardware firewalls offer this including F5’s Big-IP, you can also use the latest ISA/UMG proxy software to do SSL termination. Microsoft’s ISA 2006 has SSL termination built and is a pretty good solution. I believe UMG is the update to ISA.  SharePoint requires sticky sessions so if you are using a hardware or software based load balanced, you must have sticky sessions enabled.

Option 2
Another option is to use SSL NIC’s or my least favourite but most commonly used option is SSL on the server. You can still have your firewall in place but you don’t use a reverse proxy. I would definitely go for a reverse proxy with external access over SSL but this options is available on smaller SharePoint farms.  You can also load balance using NLB.  SSL adds about a 35% overhead to CPU resources on the server and SSL NIC cards can drastically improve CPU utilisation, however I would prefer to terminate at the firewall if possible.

Option 3
VPN solutions – Either IPSec or SSL-VPN’s are a good option but it depends on your infrastructure as setting up a VPN is a program in itself. Remote offices are already on VPN or some tunnelling technology but this doesn’t work for home users or 3rd parties as you need to give them remote access which generally involves RSA token or some sort of security token. This is the most secure option and once a user is on the network they will access your private SharePoint farm over http.

Resolution:  The general answer as always in SharePoint is "It depends ...".
I would recommend profiling all type of possible users something like

Role: Head Office User
Description: Http access from the LAN authenticating using AD.


Role: Satellite Office User
Description: Remote office has a VPN tunnel/MPLS to the head office, employees are authenticated using AD and will use http to access the SharePoint farm.

Role: Employee at home
Description: http (SSL-VPN) AD Employees have SSL-VPN access and once connected used http to view the SharePoint farm.  Authenticated using AD.


Role: 3rd Party users https SQL database or AD
Description: Suppliers need to with SharePoint, they will access 2 SharePoint load balanced servers in the DMZ using https.  The firewall is an ISA server 2006 which offers SSL termination and host header redirection.....

You can also surface the same site using different urls, so have an internal site and then a site in the DMZ.

When doing your farm architecture other points to bear in mind are redundancy, performance & licencing.  This coupled with your existing technology status and your SharePoint will provide a accessible, stable, scalable, preformant, secure SharePoint farm.   Designing your farm will reduce you licencing costs dramatically while providing the best solution to the business.

Saturday 31 July 2010

SharePoint 2010 Claims based security & Security notes

Non-Active Directory users in MOSS could support Forms Based Authentication (FBA) so can use SQL to authenticate users, or other providers.
Claims based model decouples authentication from SharePoint.  You can declaratively setup multiple providers. Using Claims Based Authentication (CBA) you can now mix multiple users from different sources in a single zone/site.
In MOSS needed a separate web.config for each set of users.
Using claims based providers can logic/meta-data to provide different users rights depending on rights.
SAML - security access markup language, used instead of Windows identity security tokens. SAM is better in that the token is extendable to give additional authority/claims. I.e. can give additional info on the security token.
CBA allows use to authenticate internal Windows users and external FBA users in the same web app.
Note: Once a claim is validated, the user is added to the SPWeb properties: Users, AllUsers & SiteCollectionUsers before they are authorised.  So as long as they have been authenticated they are added to the properties shown above.

More Info:
Claims explained on Channel 9

Tuesday 20 July 2010

SharePoint 2010 membership provider/Claims based authentication

What is Claims based authentication?
Allows SharePoint to communicate with external membership providers over open communication standards to authenticate a user. The membership provide determines if the user is valid. A token either saying the user is valid or invalid is returned. More info
Authorisation is handled by SharePoint or the logic can be applied by external membership providers.
Forms Based Authentication (FBA) works with your membership provider to give users access off a provide such as LDAP providers like Active Directory (AD).
You can also setup Windows Authentication in the "Identity Provider" where you use either NTLM or Kerbros as well as other ASP.NET providers.
The SecurityTokenService (STS) Application ensures claims tokens are being passed correctly between the provider and SharePoint (Our SPSite). STS allows for multiple providers plugged in our site. STS is setup in the web.config. More info.
Tip: Sign in Url - when setting up FBA, you can use a custom page to add business logic, for instance I assign rights/permissions when a user comes from a trusted 3rd party. More info.
Tip: FBA doesn't have to use claims based authentication as in MOSS. If you have AD but need to provide Internet access then Claims based adds no value. More info.
NTLM vs Kerbros: NTLM stands for NT Lan Manager. Microsoft's challenge response authentication protocol. Kerbros is an open standard authentication protocol, it is more secure in that it is encrypted and token are used to validate parties in the communication process. Kerbros requires ADFS.  Kerbros is therefore more secure however you do need to have a network that supports Kerbrose for it to work. Kerbros is more chatty and introduces more points of failure. NTML is more efficient. Depending on usage such as Internet it will determine the protocol.  I tend to lean towards Kerbros in larger SharePoint implementations if the network supports.  Internet scenarios don't expose ADFS to the Internet so Kerbros is not an option.

More Info:
Setting up SQL claims based FBA

Updated: 2014-02-27
Setting up ADFS2.0
Configure an Authentication Provider for a Web App to use ADFS

http://www.sharepointpals.com/post/Creating-an-ADFS20-TrustedIdentityTokenIssuer-using-PowerShell-in-SharePoint-2013
http://www.sharepointpals.com/post/How-to-Add-more-than-One-SharePoint-2013-WebApplication-to-a-SPTrustedIdentityTokenIssuer-on-ADFS-using-PowerShell