Release Notes Office 365 SharePoint Online (unofficial)


In this blogpost I am trying to gather information about updates performed in SharePoint Online and publish them here. Several feature updates are missing, please feel free to send in any comments!

Version 16.0.0.2621 (march 2014)
-SkyDrive becomes OneDrive
-OneDrive storage up to
-Office Web Apps gets updated with enhanced features
-Office Web Apps has new names Word App becomes Word Online etc|
-Content Search Web Part availlable
-Several DIV ID’s renamed

Version 16.0.x.x (september 2013)
– Maximum upload size to 2Gb
– Maximum number of sitecollections from 2.000 to 10.000

Version 16.0.1922.1200 (august 2013)
– SkyDrive Pro; personal space to 25Gb
– SkyDrive Pro; Shared with Me features, to show all documents shared with you (on SkyDrive)

Version 15.0.0.4420.1017 (february 2013)
– Initial SharePoint Online 2013 release

Version 14
– Initial SharePoint Online 2010 release

The information published on this blog is not verified by Microsoft and can contain incorrect information.

Host Multiple Provider-Hosted SharePoint Apps Within a Single Assosiated Web Application


While developing Provider Hosted Apps for our clients I noticed a lot overhead in our projects. Packaging, deploying, same code distributed over all provider hosted apps. In previous version of SharePoint we were getting used to provide a structured solution (WSP), providing a great set of features to our customers. The code was hosted within a single solution and solution package for easy release management. Although there are reasons why you should not do this, it is still a tradeoff between an easy to deploy solution and a structured way to deploy different features within a different release cycle. I don’t want to start this discussion here, but let’s take a look if it is even possible. Can SharePoint Provider Hosted Apps run within a single Web Application Project? In short, yes, it can work, although there are several reasons why you don’t want to get in to this! What we want to achieve is a solution structure were we have multiple App Manifest bound to a single App Web. In the example we have HighTrustSampleApp1 and HighTrustSampleApp2 added to the project and a Single App Web. How to accomplish this Ø Create a new solution Ø Add a SharePoint 2013 App (provider hosted); two projects will be added to you solution Ø Add a second SharePoint 2013 App (provider hosted); again, two projects will be added Ø Remove one of the webapplication Ø Select the Second App (App project) and go to properties Ø Set the Web Project the same as the Web App created with HighTrustSampleApp1 Ø Add a Second ASP.Net webpage to the project for your second app (App2.aspx) Ø Copy & Paste the codebehind from Default.aspx in the App2.aspx.cs Ø Open the App manifest of HighTrustSampleApp2 Ø Set the start page to App2.aspx Ø Ready for now! When we build and deploy this solution it will half work J. When pressing F5, to browser will pop up. If you press Trust on the second App in your project, both app will work! But effectively it is reusing the access token from the other app. Things to do in the SharePointContext & TokenHelper To authorize your App access to SharePoint your AppWeb has a library with some bunch of code to handle this OAuth handshake. Before you start believing in magic please make sure you know how OAuth works and how SharePoint authenticates your app using high or low trust techniques. The library has been delivered by default to host a single app, but in our case we are interested in hosting multiple apps in a single web app project. ClientId One of the things we need to deal with is the ClientId, which is (normally) different for every single App. The IssuerId can be shared between apps, so we can leave that one as is. The clientId is grabbed from the web.config where the clientid is registered. The ClientId should be different for the different apps, so you would need to develop a way to differentiate the app calls SharePointContext The Tokens are cached into the Http Context, so here you would need multiple session variables, one for every app Visual Studio So it looks pretty straightforward to update the code the get different different apps working within a single webapplication. But you will get annoyed by Visual Studio, because it has no support for developing multiple apps in a single Webapplication. When you are developing locally the ClientID is continuously updated to a new one on every deploy. Visual Studio registers your app for you in SharePoint and you’re good to go. Unfortunately this will not work. Conclusion For now, I have stopped my journey in exploring the ability to host multiple provider-hosted SharePoint Apps in a single web application project. Technically you can make it work, but there will be some issues on the way. We decided to continue to deploy our apps as a Virtual Application/Directory in IIS in a single Web Application for provider hosted Apps. Works great, with great support within Visual Studio. Define your apps in a scope which need to be deployed together, to minimize the App overhead. Get started with Provider Hosted Apps How to: Create high-trust apps for SharePoint 2013 (advanced topic) http://msdn.microsoft.com/en-us/library/office/fp179901(v=office.15).aspx Scripts to configure you development and production environment http://msdn.microsoft.com/en-us/library/office/dn579380(v=office.15).aspx Packaging and publishing your Provider Hosted App http://msdn.microsoft.com/en-us/library/office/jj860570(v=office.15).aspx

How To Integrate Microsoft Azure Active Directory to Authenticate SharePoint 2013 for External Users


A few days ago I was designing a new Extranet solution for one of our clients.

The customer had the following requirements for the extranet with regard to authentication of external users.

– Manage external users and groups is an easy to use interface

– Users can manage their passwords themselves

– 2-factor authentication

– No access to other resources

Our first idea was to implement external access using ADFS with the federated parties, although it will work great for other extranet scenario’s, it did not met all of our requirements.

The second idea was to use Azure with WAAD (Windows Azure Active Directory) and ACS (Access Control Services) to met our goals. The WAAD would provide identities for our environment, supports multifactor authentication and users can reset their passwords themselves!

Get Started

So lets gets started with our Proof-of-Concept! The first hit on google regarding this scenario is a great blog post from Steve Pescka (http://blogs.technet.com/b/speschka/archive/2013/05/10/integrating-sharepoint-2013-with-azure-active-directory-part-1-configuration.aspx). He wrote several blog items about this topics which was really supporting the configuration.

Prerequisities

– Azure account (https://account.windowsazure.com/signup?offer=ms-azr-0044p to sign up)

– SharePoint 2013 Environment

Create Azure Active Directory

– Login to https://manage.windowsazure.com

– Go to Active Directory

– Press Add

– If you want to use an existing Azure Active Directory (like the one you use for Office 365), choose for Existing Directory. You will be asked to re-signin with an global administrator of the Office 365 tenant, after this process the Azure Active Directory is connected to you Azure account.

– For a new directory, fill in your directory details, if you want to use a custom domain you can add this afterwards.

– The Directory is ready to use. To use the features, password reset and groups you also need to Enable Active Directory Premium

– Click on Add a user

– Fill in the wizard and choose the role “Global Administrator”

– Download the Windows Azure Active Directory Shell
http://technet.microsoft.com/en-us/library/jj151815.aspx#bkmk_installmodule

Create ACS Service in Azure

If you have already setup a ACS namespace you can skip this step.

– Go to https://manage.windowsazure.com

– Press New, and add a new Access Control namespace

– Fill in a name and region and proceed

– Your ACS namespace will now be created

Configure Identity Provider in ACS

Configure the WAAD as an identity provider in ACS

– Go to https://manage.windowsazure.com

– Go to Active Directory

– Go to Access Control Namespaces and select your newly created namespace

– Go to Manage

– Go to Trust relationshops > Identity Providers

– Click on Add Identity Provider

– Choose a WS Federation provider

– Fill in a Descriptive Name and use https://accounts.accesscontrol.windows.net/<waad-name>/FederationMetadata/2007-06/FederationMetadata.xml as WS metadata URL. Provide your own WAAD or use a more general approach to allow multiple WAAD’s to sign in to your SharePoint 2013 environment using the federation url https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml

Configure Relying Party Trust in ACS

Now we need to configure the on-premises SharePoint 2013 environment as the relying party

– Go to relying party applications

– Click on Add, choose to enter settings manually.

– Fill in a realm, in this example urn:sharepoint:acs, but it can be any realm (and take note of this, we need this later on)

– Select Token form SAML 1.1. (unfortunately SharePoint 2013 (and 2010) do not support SAML 2.0)

– Select the identity provider selected earlier

– Press Save

Configure Group Rules

Now we need to generate and configure the claim translation from the WAAD claim to an workable claim for SharePoint 2013.

– Go to Group Rules

– Click on Add, fill in a Group name “AAD Rules” and click Save

– Click on Generate

– Select the IdP created earlier and click Generate

– Select the Output claim UPN

– Set the input claim type to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name instead of upn, because this input claim is empty. The name claim will contain the upn.

– Set the output claim type to http://schemas.microsoft.com/ws/2008/05/identity/claims/upn , which will be accepted by the STS of SharePoint.

– Click on Save

Enabled Application for WAAD to authenticate

– Execute the following Powershell

<code>

$replyUrl = New-MsolServicePrincipalAddresses –Address “https://<youracs>.accesscontrol.windows.net/v2/wsfederation”

New-MsolServicePrincipal –ServicePrincipalNames @(“https://<youracs>.accesscontrol.windows.net/”) -DisplayName “Joran Markx Tenant” -Addresses $replyUrl

</code>

Configure SharePoint to use ACS

– Go to Development -> Application integration

– Copy and paste the WS-Federation Metadata into the internet browser

– Copy and paste the base64 code in EntityDescriptor>RoleDescriptor>KeyDescriptor>..>X509Certificate to a notepad and save as .cer file (Certificate)

– Open the certificate to check if it is working great! If it does not, please check if you copied the whole X509Certificate and the file is saved with ANSII.

– Copy the .cer to the SharePoint 2013 Server

Create and configure STS in SharePoint

Now we need to create a new Trusted Root Authority and configure the Trusted Identity Token Issues.

– Open the SharePoint Management Shell (as Administrator)

<code>
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:aadcert.cer”)

New-SPTrustedRootAuthority -Name “ACS Token Signing Certificate” -Certificate $cert

$map = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/05/identity/claims/upn” -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname” -IncomingClaimTypeDisplayName “GivenName” -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname” -IncomingClaimTypeDisplayName “SurName” -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/jobtitle” -IncomingClaimTypeDisplayName “JobTitle” -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/office” -IncomingClaimTypeDisplayName “Office” -SameAsIncoming

$realm = “urn:sharepoint:acs”

$ap = New-SPTrustedIdentityTokenIssuer -Name “AAD” -Description “ACS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7 -SignInUrl “https://litware.accesscontrol.windows.net:443/v2/wsfederation” -IdentifierClaim http://schemas.microsoft.com/ws/2008/05/identity/claims/upn
</code>

– Create or configure a webapplication in SharePoint with Claims Authentication and select the new TrustedIdentityToken Issuer

– Authorize add at least one user from the WAAD to the a site in the webapplication

– You’re ready to go!

Test the solution

– Fire up a browser and go to your SharePoint site

– Select AAD, you will not get this screen if you disable Windows Authentication (and have only one authentication provider)

– Then select one of the IdP in ACS, you will not see this screen if you only have one IdP configured.

– You will now get the Azure Active Directory Login screen

– After entering your username and password, you will be redirected to SharePoint 2013 and will be logged in!

Known issues

– People picker will not find people in the directory
http://blogs.technet.com/b/speschka/archive/2013/05/12/integrating-sharepoint-2013-with-azure-active-directory-part-2-the-custom-claims-provider.aspx