by Martin Laukkanen | Jul 23, 2013 | Apps, Development, How to, SharePoint 2013
One of the noticeable gaps that comes up immediately when you start planning any significant SharePoint 2013 deployment with requirements such as multi-tenancy and SAML based authentication (ADFS, ACS, etc) are the some of the limitations with the new features of 2013.
One such limitation is the new App Store which only supported Windows Authentication and didn’t support hostheaders at RTM! Fortunately Microsoft fixed the hostheader limitation in the March PU release (KB2768001), however the SAML limitation remains.
Steve Peschka wrote about one solution to part of this problem here: Using SharePoint Apps with SAML and FBA Sites in SharePoint 2013, however that only covers the Provider hosted (or Autohosted) apps, which leaves a big gaping hole where the simplest Apps of all are not supported.
The Problem with SharePoint hosted Apps
Basically the problem is in the the App Domain configuration and authentication requirements, take a typical example:
- First tenant:
App Domain: https://tenant1-*******.contosoapps.com
- Second tenant:
App Domain: https://tenant2-*******.contosoapps.com
As you know those App Domains are auto created for each installed app with a unique name per app. (Note that you need March PU to configure the above App Domains)
So with that in mind, when a user is authenticated to tenant1.contoso.com that does not automatically authenticate them to tenant1-******.contosoapps.com forcing re-authentication, that’s where we hit our problem.
Azure ACS and ADFS – No Apps??
Unfortunately Azure ACS and ADFS don’t work at all in this scenario. The problem:
UseWReplyParameter while supported by both is restricted to sub sites only (e.g. reply to , as a result in our scenario above what you end up with is this annoying authentication loop:
The reason for this is for security, as allowing any arbitrary WReply parameter could potentially allow an attacker from one Relaying Party (RP) to be redirected with a valid authentication token to a second RP.
So in my scenario above it may be possible for tenant1 users to authenticate not only with tenant1*** apps, but also tenant2 sites!
Solutions?
Unless Microsoft changes ACS and ADFS (unlikely) or they modify the SPTrustedIdentityTokenIssuer (maybe?), then the only option right now is to roll your own STS Identity Provider based on the the Windows Identity Framework SDK!
Fortunately you’re not alone, plenty of examples of this exist;
And my favourite:
Lots of good examples to work with but for this blog I’m going to extend the last one on the list by Steve Peschka using SAML with Microsoft Accounts (LiveID). So if you want to implement my changes below, you’ll need to start by reading the last article above and download and get familiar with the source for that one.
Changes to WindowsLiveOauthSts Solution
In summary we need to make the following changes to the solution:
- Firstly we need to update the Custom STS to accept and use the WReplyParameter.
- Secondly we need to capture the original request WReplyParameter in the PassiveSTS.cs and send it to the Custom STS.
- Finally we need to ensure that we maintain the security of our solution in with all changes.
That’s it, simple hey?
Updates to CustomSecurityTokenService.cs
First add somewhere to store the parameter to the class:
protected String WReplyParameter { get; set; }
Next extend the constructor to accept the parameter:
public CustomSecurityTokenService(CustomSecurityTokenServiceConfiguration configuration,
Dictionary<string, string> ClaimValues, String wReplyParameter = "")
: base(configuration)
{
this.oAuthValues = ClaimValues;
this.WReplyParameter = wReplyParameter;
}
And finally use the saved value in the GetScope() method:
// Set the ReplyTo address for the WS-Federation passive protocol (wreply).
// Use the provided WReplyParameter if it exists
if (String.IsNullOrEmpty(WReplyParameter))
scope.ReplyToAddress = scope.AppliesToAddress;
else
scope.ReplyToAddress = WReplyParameter;
return scope;
Updates to PassiveSTS.cs
First we have to get the Query String parameter from the request:
string wReplyParameter = HttpUtility.ParseQueryString(HttpUtility.UrlDecode(state))["wreply"];
Then we make sure to pass the parameter to the CustomSTS when instantiated:
//create an instance of our sts and pass in the dictionary of values we got from Windows Live oAuth
SecurityTokenService sts =
new CustomSecurityTokenService(CustomSecurityTokenServiceConfiguration.Current, values,
wReplyParameter);
Security Considerations
The risk arises if we allow any ‘wreply’ parameter to be be used as our returned ReplyToAddress in the Custom STS, in this example implementation a simple validation is included using an array of allowed URL’s (unmodified code quoted here);
// TODO: Set enableAppliesToValidation to true to enable only the RP Url's specified in the
// PassiveRedirectBasedClaimsAwareWebApps array to get a token from this STS
static bool enableAppliesToValidation = false;
Obviously for a production multi-tenanted environment you would need something more sophisticated, but I’ll leave that to you. Also another thing that particular solution does not allow for is our dynamically created App Domains, so that too will require some changes.
But hang on..
However it is worth saying here that in our simple example when using only Live ID across all Web Apps we have not exposed anything extra (yet) with this change! Think about it; if an attacker in wants to login to Tenant2 then all they need to do is open and login! Our STS is passing only identity and user related claims so all of the securing of resources is left to the tenant. IE; John from Tenant 1 has no site collection SPUser rights to Tenant 2 sites! So as it stands this scenario is similar to an equivalent Azure ACS implementation using multiple Relaying Parties.
Final Words
It’s worth mentioning that this likely will become redundant after a future service pack, assuming Microsoft fixes this by changing SharePoint that is.
A good indication is to look at how Office365’s doing it right now, and a quick Fiddler trace shows that the two cookies (rtFa and FedAuth) are passed directly to the AppDomain from the tenant Web App, so clearly MS is handling this in the initial Auth.
That may be a topic for investigation another time.
Hope this is useful for someone out there.
by Martin Laukkanen | Mar 13, 2013 | Development, How to
One of the great features of Claims authentication in SharePoint (2010 or 2013) is the ability to use external authentication providers such as ADFS, Microsoft LiveID (Hotmail, Outlook.com etc) or even Google among others. Better yet, using Microsoft Azure ACS makes setting up and managing this for extranet sites or Cloud applications simple!
The Catch!
However there’s one catch (isn’t there always?) Microsoft Live ID doesn’t give the email address in the claim. This sounds obscure but in effect what it means is that once you configure all of this this is what you get:
What a nice and friendly username!
(If you want instructions on configuring all this, I highly recommend Wictor Wilén’s indispensible series of articles on the topic: http://www.wictorwilen.se/Post/Visual-guide-to-Azure-Access-Controls-Services-authentication-with-SharePoint-2010-part-1.aspx)
Solutions?
Most people suggest using something like Google to authenticate instead to avoid this, however with SharePoint Online, Project Online, EPMonDemand (ahem – excuse the blatant plug!) and Office365 all tied to my LiveID, I personally don’t think that’s an option!
So basically we need to populate that information, sure we could ask users to do it manually, but better yet let’s find out how to do this the Microsoft way.
Live Connect API
In order to support Windows 8 apps, Web apps and all manner of mobile devices MS have this great resource available, head over to the Live Connect Developer Center to see more information. Once you’ve registered then you can follow my steps below to get you setup to auto-populate SharePoint user information via Javascript!
Getting this going
Note: Getting to the business end here; you’ll Visual Studio, some JavaScript, SharePoint Object Model and WebPart development experience to continue. (Or just skip to the end and download my example, like everyone else!)
Firstly you’ll need to create yourself an ‘application’ on Live Connect, something like the following:
The important thing is to note your Client ID, and then enter the correct URL under Redirect domain.
All done, easy!
If you want to see how all this works, the Interactive Live SDK is one of the best SDK implementations I’ve seen from MS, have a look at what kind of options are available to you.
For example, the following JavaScript will return the basic user information for the currently logged in user including name, email addresses and more;
WL.init({
client_id: “***********”,
redirect_uri: “callback.aspx”,
response_type: “token”
});
WL.login({ “scope”: “wl.emails” }).then(
function (response) {
updateUserData();
},
function (response) {}
);
function updateUserData() {
WL.api({ path: “/me”, method: “GET” }).then(
function (response) {
// Do something here!
},
function (response) {}
);
}
Neat hey?
Bring it all together
Okay not quite done yet, lets put this into a nice simple SharePoint webpart and then using the good old Object Model update the current users’ details.
What you need to do:
- Open Visual Studio and create a new SharePoint – Visual Web Part Project
- Create some ASP controls for your webpart, I won’t bore you with all the details here, get the full solution below in which I created the following:
- AccountTextBox
- NameTextBox
- EmailTextBox1
- UpdateButton
- Plus a bunch of labels to make things neat.
- We need a link to the Live Connect http://js.live.net/v5.0/wl.jsfile, to make this easier I have saved a copy in a Layouts folder in my solution, so my ScriptLink looks like this:
<SharePoint:ScriptLink ID="LiveIdscript" runat="server" Name="UpdateUserWebPart/wl.js"></SharePoint:ScriptLink>
- Also for the Live ID bit to work we need a callback.aspx file in our solution, which is referenced in the “redirect_uri” parameter passed to to WL.init in the JavaScript, this file should look something like the following;
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Authentication Complete</title>
</head>
<body>
<!--
The script will handle passing oauth/authorize response back to the calling page.
-->
<script src="/_layouts/15/UpdateFromLiveID/js/wl.js" type="text/javascript">
</script>
<p>This window can be closed.</p>
</body>
</html>
- Now for the JavaScript, first we need to initialise and try to login to Windows Live.
<SharePoint:ScriptBlock ID="ScriptBlock1" runat="server">
WL.init({
client_id: "*************",
redirect_uri: "<%=SPContext.Current.Web.Url %>/_layouts/15/UpdateUserWebPart/callback.aspx",
response_type: "token"
});
if (document.getElementById("<%=EmailTextBox1.ClientID %>").value == '') {
WL.login({ "scope": "wl.emails" }).then(
function (response) {
updateUserData();
},
function (response) {}
);
}
Above I’ve included an IF that checks for an existing Email address, if none is found then it automatically tries to login. (Pop-up blockers hate this, so you’ll need to do something nicer)
- Next here’s my updateUserData() function which is called on successful login;
function updateUserData() {
WL.api({ path: "/me", method: "GET" }).then(
function (response) {
document.getElementById("<%=EmailTextBox1.ClientID %>").value = response.emails.preferred;
if (!response.name) {
document.getElementById("<%=NameTextBox.ClientID %>").value = response.emails.preferred;
}
else {
document.getElementById("<%=NameTextBox.ClientID %>").value = response.name;
}
document.getElementById("<%=UpdateButton.ClientID %>").click();
},
function (response) {}
);
}
</SharePoint:ScriptBlock>
So once we have the user data we update our ASP controls created previously so we can use those in the code behind.
- Lastly we need some code behind to get the details and update our SPUser object.
protected void Page_Load(object sender, EventArgs e)
{
if (string.IsNullOrEmpty(AccountTextBox.Text))
{
AccountTextBox.Text = SPContext.Current.Web.CurrentUser.LoginName;
NameTextBox.Text = SPContext.Current.Web.CurrentUser.Name;
EmailTextBox1.Text = SPContext.Current.Web.CurrentUser.Email;
}
UpdateButton.Click += UpdateButton_Click;
}
- Here I’m updating the controls on Page_Load but only once, then creating an event for our Button.
- For the button I basically do the following:
void UpdateButton_Click(object sender, EventArgs e)
{
[...]
SPUser currentUser =
elevatedWeb.SiteUsers.GetByID(SPContext.Current.Web.CurrentUser.ID);
currentUser.Name = NameTextBox.Text;
currentUser.Email = EmailTextBox1.Text;
currentUser.Update();
[...]
}
To keep this short(er) I have cut out the RunWithElevatedPrivileges bits and such, you actually might not need to have that depending on your user permissions, but if you leave it in then I suggest reading this.
Are we done yet?
Now lets deploy and have a look;
That’s what we see initially, but once we allow that popup:
Make sure you select Yes.
Nice.
Now if everything’s working, clicking Update should do just that!
Hurrah!
Get my full example solution here built for Visual Studio 2012 in SharePoint 2012, just make sure you update it with your Client ID from Live Connect.
Conclusion
It’s not perfect, in fact it’s a way off (think application pages, modal dialogs, mmm), but hopefully this will get you started.
Any questions, post below, but I strongly recommend you play with the Interactive SDK on Live Connect and read the Getting started documentation there if you have any problems with the JavaScript. It took me quite a bit to get all that working together the first time!
Update: See my latest post on this topic for a better approach: http://nearbaseline.azurewebsites.net/blog/2013/07/sharepoint-hosted-apps-with-saml-authentication/
by Martin Laukkanen | Jun 3, 2011 | How to, Project 2010, SharePoint 2010
A common requirement for many SharePoint and Project Server deployments is to have an external facing interface using an alternate Forms based authentication method, the most common is using an ASP.NET SQL provider which since the 2007 version is the one of the simplest options. With 2010 however and Claims authentication this requires that you convert your existing Windows authenticated Web Applications to Claims based NTLM authentication, this process is well documented online for SharePoint 2010, however I have recently found that with Project Server 2010 a number of problems can be encountered.
Here is a typical error with the Project Details webpart after conversion:
[Hi Google: (An unknown error has occurred)]
In this blog I’m not going to cover the whole process of setting up Extranet access, I’ll leave it to you to read some of the other excellent blogs on the topic linked below. What I will cover is how to do the not-so-well documented parts.
To Start With: Procedure to Setup Extranet Access
The general procedure for extending a Project Server application for extranet users is something like this:
- Provision a ASP.NET SQL membership Provider.
- Extend the Web Application to add an Extranet zone.
- Configure the Claims membership providers in the web.config files.
References for these steps:
- MMohanty: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
- Geoff Varosky: http://gvaro.wordpress.com/2011/03/28/planning-and-configuring-extranets-in-sharepoint-2010part-1/
- Geoff Varosky: http://gvaro.wordpress.com/2011/04/01/planning-and-configuring-extranets-in-sharepoint-2010part-2/
If you have followed those steps discussed in the links, then when you will likely have found that you are seeing all sorts of security issues after changing your Classic Web App to Claims.
In short the error above originates from the procedure used to migrate the application to Claims:
(WARNING: Don’t use the above commands!)
Unfortunately this does not fully migrate the SharePoint application and from my experience will lead to errors such as the first one above.
Migrating the Web Application to Claims Without Issues
Fortunately Microsoft has a well documented procedure: http://technet.microsoft.com/en-us/library/gg251985.aspx
$WebAppName = "http:// yourWebAppUrl"
$account = "yourDomainyourUser"
$wa = get-SPWebApplication $WebAppName
Set-SPwebApplication $wa -AuthenticationProvider `
(New-SPAuthenticationProvider) -Zone Default
Note: that the above commands migrate ALL Web Applications sharing that URL, it is not possible to only migrate your Extended application!
That command will migrate the web application fully and prepare it for Claims authentication, and don’t forget the TechNet article discusses the need to update your portalsuperreaderaccount and portalsuperuseraccount accounts if they have been set, which can be done easily using the following commands:
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domainapppool"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|domainapppool"
$wa.Update()
Migrating Users to Re-enable Login
Once your Web App is in Claims mode then you will still need to migrate your AD users, this part is not so well documented.
Essentially you need to use the PowerShell command Move-SPUser to move all of your existing “DOMAINusername” users to the new Claims-NTLM identity “i0#.w|domainusername”.
Before you can do this you need to ensure that your admin user has permissions to access this site, this can be done from Central Admin by updating the Web Application Policy:
Add or re-add your user account (DOMAINadminuser) with Full Control to the web application in question, before proceeding with the following steps. (Note: the above Policy should now show your Admin user with the User Name like so; “i:0#.w|domainadminuser”)
Next, here is the command to migrate a single user:
Get-SPUser -web http://server/pwa -identity "DOMAINuser" | Move-SPUser -NewAlias "i:0#.w|domainuser" –IgnoreSID
The command will actually give the following error:
However if you then use Get-SPUser you will note that the account has actually been migrated.
So for my purposes I wrote the following script which will migrate all users without the claims prefix “i:0#.w|” (Yep ignore those errors!):
$UsersToMigrate = Get-SPUser -web http://server/pwa | `
where {$_.UserLogin –like ‘DOMAIN*’ }
ForEach ($user in $UsersToMigrate)
{
Get-SPUser -web http://server/pwa -identity $user | Move-SPUser `
-NewAlias ("i:0#.w|"+$user.UserLogin.toLower()) -IgnoreSID
}
After running the above, users should now be able to login to your migrated Web Application with any AD user!
If you see other errors running either that script or the above command by itself, make certain that you can do the following without errors:
Get-SPUser –web http://server/pwa
If not check your web policy again as above.
Finally Adding Your Claims Users to PWA
Now we have a fully migrated Claims-NTLM Web Application in addition to a newly created Extranet Claims Web Application which is attempting to use a Forms membership provider (SQL-MembershipProvider if you following the steps linked above).
The next steps are again well documented in the links above, configure your web.config files and then setup your SQL users.
The final problem you may face when attempting to add your new forms users to PWA, assuming (if using SQL that your ASPNETDB database permissions are correctly set) then adding the users to SharePoint will be easy using Site Actions – Site Permissions – Grant Permission, however what you will may see when attempting to add to Users to PWA is an error like the following:
(Error Message: The NT account specified is invalid. …)
This is because the user has not yet been added to the SharePoint site collection which fortunately is easy enough to fix, just add the user to SharePoint from Site Permissions first!
From Site Actions –> Site Permissions:
As long as SharePoint can find the user (make sure to use the full username!) then once you hit Ok the user identity will be added to the Site Collection, and then you will be able to add the user to PWA!
FYI if like me you like doing things in bulk here’s the PowerShell command to do the above:
New-SPUser -UserAlias "i:0#.f|SQLMembershipProvider|JaneDoe" -Web http://server/pwa -DisplayName "Jane Doe" -Email [email protected]
All done, enjoy your forms membership provider!
by Martin Laukkanen | Jan 12, 2011 | SharePoint 2010, Troubleshooting
With a large customer going live on a fully multi-tenanted claims authenticated platform in the last month I’ve had the chance to really see the limits of these two new features in SharePoint 2010. This issue was one of the big impact problems that I’m hoping that I’ve now found the solution to, so with that in mind it’s definitely worth sharing.
Problem:
After a few days of working normally claims authentication stops working unexpectedly on any given server in the farm, the below errors are logged.
Event Logs
Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation
Event ID: 8306
Task Category: Claims Authentication
Level: Error
Description:
An exception occurred when trying to issue security token: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs..
Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation
Event ID: 8306
Task Category: Claims Authentication
Level: Error
Description:
An exception occurred when trying to issue security token: The security token username and password could not be validated..
Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Event ID: 1511
Task Category: None
Level: Error
Description:
Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.
ULS Logs:
01/04/2011 13:38:52.17 w3wp.exe (0x037C) 0x0660 SharePoint Server Shared Services olgq Exception System.Runtime.InteropServices
.COMException (0x800703FA): Illegal operation attempted on a registry key that has been marked for deletion. at System.DirectoryServices.DirectoryEntry.Bind(…
01/04/2011 13:38:52.17 w3wp.exe (0x0554) 0x0F30 SharePoint Foundation Claims Authentication 8306 Critical An exception occurred when trying to issue security token: The security token username and password could not be validated..
Cause:
The third the Event log error above I included as although it is one that you often see, it was the message that eventually led me to the what looks like the source of this issue, with that combined with the “registry key that has been marked for” message in the ULS I was lead to the following DCOM blog:
Resolution:
It seems that the Claims provider breaks when for some reason or other the App Pool account logs off unexpectedly, the solution (at least after 2 weeks with no reoccurrence) is as suggested in the above blog;
As a workaround it may be necessary to disable this feature which is the default behavior. The policy setting ‘Do not forcefully unload the user registry at user logoff’ counters the default behavior of Windows 2008. When enabled, Windows 2008 does not forcefully unload the registry and waits until no other processes are using the user registry before it unloads it.
The policy can be found in the group policy editor (gpedit.msc)
Computer Configuration->Administrative Templates->System-> UserProfiles
Do not forcefully unload the user registry at user logoff
Change the setting from “Not Configured” to “Enabled”, which disables the new User Profile Service feature.
‘DisableForceUnload’ is the value added to the registry
I’ll update this blog entry if the problem comes back.
by Martin Laukkanen | Jul 31, 2010 | SharePoint 2010, Troubleshooting
When restoring SharePoint 2010 databases or sites I have recently come across the following problem:
Access Denied to all Sites for all users, including Site Collection Admins.
This appears similar to old 2007 restore issues which were fixed using the STSADM MigrateUser command, however in this case it seems that the STSADM (or PowerShell move-spuser) commands doesn’t fix the issue. And I have definitely made certain to change the Site Collection admin on the restored site collections using Central Admin.
A little investigation revealed that the reason is the use of Claims (or Forms) Authentication in either the source or destination web application, so in my case where my Test environment used Claims (both NTLM and LDAP) but my Prod was only going to use NTLM authentication the restored sites were inaccessible (including PWA!).
Fortunately in my case I found a workaround; setup my new Web App to use Claims, however only enable NTLM authentication, effectively resulting in a pure NTLM setup. However that won’t always work, in fact I have another case where the source data (from an old 2007 portal) is using NTLM and I want to migrate it to 2010 using Claims, in that case another solution will be required.
I plan to investigate further using the "move-spuser" powershell command as that seems to be the solution, it just seems that something is preventing it from migrating the users as expected. I’ll update this blog with my results.
