Skip Ribbon Commands
Skip to main content

SharePoint Developer Reference - Blog

:

Home
March 14
Slides and demos of my session “Office 365 API for .NET Developers” at SPS Helsinki

Thanks for attending my session @SPSHelsinki, here you can find the slides deck I showed during my session. Moreover, on the OfficeDev PnP project you can find the entire demo solution I illustrated during the session. There you will find a WPF application, an ASP.NET MVC web application, and an ASP.NET WebForm application to see how to consume the Office 365 API from .NET.

Thanks again and enjoy the Office 365 API!

March 11
Microsoft Office 365, ADFS and signing/encrypting certificates renewal

Let’s say that you have an Office 365 tenant, and that you also deployed a set of Federated Identities with Windows Active Directory Federation Services (ADFS). It could happen that you log into the Admin portal of your Office 365 tenant and you see the following polite message.

Office365-Alert

Let me repeat the text to help people find this content, via web search, in case of need: “Renew your Certificates – One of your on-premises Federation Service certificates is expiring. Failure to renew the certificate and update trust properties within X days will result in a loss of access to all Office 365 services for all users.” Wow! That’s a very clear message, but very scaring, as well. What’s happening?!

Well, from an ADFS perspective you will have at least three certificates to support the security of your own environment:

  • The “Service Communications” certificate, which will be used to protect the HTTPS endpoint
  • The “Token-decrypting” certificates, which will be used to decrypt security tokens
  • The “Token-signing” certificates, which will be used to sign security tokens

The first one is used to secure the HTTPS endpoint, and when it expires you simply need to renew it and replace it in your ADFS and in your reverse proxies, as well and if any.

Meanwhile in your environment, which is federated with Azure Active Directory, the last two certificates are used to secure the security token exchange with Azure AD, which sits under the cover of your Office 365 tenant.

The kind message you get in the Office 365 Admin center simply states that one or both of these certificates are going to expire and, if you will not replace them promptly, nobody will be able to consume your services after the effective expiration of those certificates. Luckily you also have the “Update Now” link, at the very end of the alert. If you click on it you will be redirected to a Wiki page (created on March 2011 and updated on February 2015), which mainly targets ADFS 2.0 on Windows Server 2012. Now, my personal suggestion is to leverage Windows Server 2012 R2 and ADFS 3.0 for federating identities with Azure AD and Office 365, if it is possible.

Well, using ADFS 2.0 or ADFS 3.0 the solution to the problem is almost automatic, if you enable the AutoCertificateRollover capability. Let’s see.

Connect to your ADFS server and open PowerShell console or PowerShell ISE. Run the Get-AdfsProperties cmdlet and watch the output:

ADFS-Properties-Highlighted

You will find some interesting properties like:

  • AutoCertificateRollover (default value TRUE): determines if the ADFS service will automatically manage the enrollment of new certificates before expiration of current ones.
  • CertificateCriticalThreshold (default value 2): is the number of days, before the current certificates expiration, that will determine a critical self-enrollment of new certificates to replace the current ones, which are going to expire. It shouldn’t happen if the auto certificate rollover procedure works properly.
  • CertificateDuration (default value 365): defines the duration in days of the enrolled certificates.
  • CertificateGenerationThreshold (default value 20): is the number of days, before the current certificates expiration, that will determine when the certificate auto-rollover procedure will be executed. That procedure will generate new certificates that will soon replace the current ones. Initially the new auto-generated certificates will be “Secondary,” and the current certificates will keep their status of “Primary” certificates.
  • CertificatePromotionThreshold (default value 5): defines the number of days during which the new certificates will be “Secondary.” After that, there will be a switch between the certificates: the expiring ones will become “Secondary”, while the new ones will become “Primary.”

More details about these ADFS properties, and some others, can be found here.

In the demo environment that I am showing you I had the expiration date for my encrypting and signing certificates set on March 27th 2015, as you can see in the following figure.

ADFS-Certificates-Highlighted

Well, on March 7th 2015, which is exactly 20 days (= CertificateGenerationThreshold) before certificates expiration, ADFS 3.0 automatically generated a couple of new certificates for encrypting and signing. Moreover, ADFS 3.0 set those new certificates as “Secondary.” Here you can see.

ADFS-Certificates-Double-Highlighted

This way, the Azure AD engine is able to retrieve the information about these two new certificates within the next 5 days (= CertificatePromotionThreshold). In fact, on March 10th 2015 the polite alert disappeared from my tenant Admin center, as you can see in the following figure.

Office365-NoMore-Alert

Lastly, on March 13th 2015 (i.e. today), the ADFS 3.0 engine switched the “Primary” and the “Secondary” certificates, in order to promote the new ones and demote the expiring ones. Here is the result in the ADFS administration console.

ADFS-Certificates-Double-Switched-Highlighted

And you are done! Your ADFS certificates are updated, the Azure AD tenant is aware of the new certificates, and for the next 365 days (= CertificateDuration) - after the creation date of the new certificates - you don’t need to care about certificates expiration. Your users can continue consuming their services without any service interruption.

When the Secondary (old and expiring) certificate will effectively expire, ADFS will automatically remove it from the list of available certificates, and only the Primary and valid (not expired) one will survive.

February 16
Slide, demos and links of my webinar “Consuming Office 365 REST API” for ESPC15

Here you can find the demos (on OfficeDev/PnP project) about how to consume the Office 365 APIs. The slides and the recorded video will be available soon on the European SharePoint & Office 365 Community.

Moreover, as promised, here you can find the list of libraries (released and beta) available to consume Azure AD: https://msdn.microsoft.com/en-us/library/azure/dn151135.aspx .

I hope you enjoyed my webinar, and hope to meet you again shortly.

My next stop Sorriso will be in Helsinki, March 14th.

February 15
SPSSTHLM18 -  Advanced SharePoint Workflow Scenarios

And here you can find slides and demos of my session “Advanced SharePoint Workflow Scenarios” at SharePoint Saturday Stockholm, 14 February 2015.

Stay tuned … the workflow topic is a huge one!

February 15
SPSSTHLM17 – Inside SharePoint Apps Security

Here you can find slides and demos of my session “Inside SharePoint Apps Security” at SharePoint Saturday Stockholm, 14 February 2015.

I hope you enjoyed the session and hope to meet you again in the near future!

January 12
SharePoint App and “Invalid JWT token” exception

Let’s say you have a SharePoint App deployed on SharePoint Online, in Microsoft Office 365, and working since many months ago. Suddenly, it stops working and when you try to access it, you get back an exception like this:

System.IdentityModel.Tokens.SecurityTokenException: Invalid JWT token. Could not resolve issuer token.

That’s what happened to me today (I know, I’m a lucky boy!). Well, first of all I inspected the OAuth protocol flow using Fiddler and the Fiddler Extension for SharePoint App Token, which is available thanks to Kirk Evans. Thus, I noticed that in the SharePoint App Token of the failing app there was a difference, if compared with the App Token of a working app.

Here you can see the trailer of the token issued by ACS for the failing app:

{"typ":"JWT","alg":"RS256","x5t":"kriMPdmBvx68skT8-mPAB3BseeA"}{"aud":"a683fa34-b747-48cd-adc8-bfca2778684b/myfailingapp.azurewebsites.net@7f86dcab-5543-431d-a979-f5b7cd4912df","iss":"00000001-0000-0000-c000-000000000000@7f86dcab-5543-431d-a979-f5b7cd4912df", …. }

And, here you can see the trailer of a token issued by ACS for a good one:

{"typ":"JWT","alg":"HS256"}{"aud":"912c71d7-6525-4b22-a6c2-01d3fd1bdd77/myworkingapp.azurewebsites.net@7f86dcab-5543-431d-a979-f5b7cd4912df","iss":"00000001-0000-0000-c000-000000000000@7f86dcab-5543-431d-a979-f5b7cd4912df",….}

Well, can you see the difference? Of course, the failing app receives a JWT token that is signed using an X.509 certificate and the RSA with SHA-256 algorithm. The x5t header parameter provides the encoded value of the thumbprint of the X.509 certificate used. While the good app uses an HMAC SHA-256 algorithm, instead.

And so what about the issue? After discussing with some of my friends and colleagues of the deceased :-) MC(S)M community, it came out that a Shared Secret of an app expires one year after the creation, and you have to renew it manually. Thanks to Oliver Zeiser and Neil Hodgkinson (@nellymo) I got a link to an article on MSDN, which explains exactly how to renew a Shared Secret for an app, without changing the Client ID. Here is the URL of the article “How to: Replace an expiring client secret in an app for SharePoint”: http://msdn.microsoft.com/en-us/library/office/dn726681(v=office.15).aspx

And by applying what is illustrated there, everyone lived happily ever after! :-)

In case you will have the same kind of issue, I hope this blog post will help you solve it quickly, correlating the error message with the solution. Enjoy!

December 04
Slides and demos of my session at SPSUK2014

Hello everybody, thanks again for attending my session about “Real life experiences with the SharePoint Workflow” at the SPSUK2014.

Here you can find the slides (in PDF format) of my session.

I decided to share the demos with the whole SharePoint Community through the great Office365 PnP project.

Some of the demos I showed you are already available in the Office 365 PnP project, in the master branch, while the others are already available in the dev branch, and will be published shortly in the master branch.

Enjoy!

October 30
SP Friday Budapest 2014 – Publishing SharePoint Apps on Microsoft Azure - Demos and Slides

Here I am with slides and demos of my talk at the latest SP Friday Budapest. I really enjoyed being part of the event, and I want to thank Agnes for inviting me.

About the demo, let me briefly explain the main steps to publish a SharePoint App on Microsoft Azure.

In case of need, let’s create a new Office 365 Developer Subscription, going to the following URL.

Start Visual Studio 2013 and create a SharePoint App project.

  1. Target SharePoint Online in Office 365 or SharePoint Server 2013 on-premises
  2. Choose your preferred development model. My one is ASP.NET MVC.
  3. If you are targeting SharePoint Online, choose Azure Access Control Services (ACS) for apps Authorization. If you are targeting SharePoint 2013 on-premises, choose the Server to Server (High Trust) authorization model.

Now, develop your app. I would suggest you to replace the out of the box file in Views/Shared/_Layout.cshtml with this new one, which includes all the stuff needed to support the Office 365 and the SharePoint Chrome control. The new file mainly declares the chrome control placeholder and includes the spcontext scripts needed to support SharePoint and the SharePoint App model. In order to properly support the SharePoint Chrome control you should also replace the out of the box Scripts/spcontext.js file in SharePoint app web site with the following one. It will include a bunch of JavaScript loaded from the host web site and declared in the SP.UI.Controls.js file. You should also add the app icon AppIcon.png to the target SharePoint App web site project.

SpApp-Project-Outline

Implement your business logic and debug your solution. Once you’re ready to test the SharePoint App, just press F5 and play with it. The local IIS Express engine will provide you all the capabilities to run the app locally.

Whenever you will be ready to publish your app, simply right click on the SharePoint App project and choose “Publish” from the context menu.

Publish-Screen

Visual Studio 2013 will ask you to create or select a publishing profile.

Publish-Your-App

To target Microsoft Azure and an Azure Web Site, you will simply need to create an Azure Web Site using the Microsoft Azure management portal. Then, download the publishing profile file and choose it from the following Visual Studio wizard.

Publishing-Profile-Step1

Just after that, you will have to provide the Client ID and the Client Secret for your SharePoint App. You can get these values using the Reseller Dashboard provided by Microsoft, if you want to publish your app on the Office Store. If you are targeting the Corporate App Catalog (on Office 365 or on-premises), which is more often the case, you can simply open the App Catalog site collection and navigate to the /_layouts/15/AppRegNew.aspx page of that site.

AppRegNewPage

There you will be able to register a new Client Id and the Client Secret for your app, from an OAuth 2.0 perspective. Record the generated values, because after creating them you will not be able to access the Client Secret anymore. Write those values into the “Set app identity” step of the “Publish apps” wizard.

Publishing-Profile-Step2

Now, within the “Publish your app” page select the “Deploy your web project” button. Visual Studio 2013 will publish your SharePoint App Web Site on the target Azure Web Site. Visual Studio will also change the web.config file of the target Web Site in order to include the Client ID and Client Secret you just registered.

After that, you can click the “Package app” button in the “Publish your app” page and create the .app file that describes your app. Upload the output .app file onto the App Catalog, under the “Apps for SharePoint” library, or onto the Reseller Dashboard if you are targeting the Office Store.

Now, you are ready to add your app on a target Site Collection. Enjoy!

October 30
SharePoint Days Slovenia 2014 – Slides

Here I am with the slides of my sessions at SharePoint Days Slovenia 2014.

I hope you enjoyed my sessions and let’s see in the future. Feel free to contact me in case of need at paolo(at)pialorsi.com or via Twitter (@PaoloPia).

October 30
SPC Adriatics 2014 – Demos and Slides

Sorry for being late, but I had some personal troubles that didn’t allowed me to follow up earlier. Nevertheless, in this post I want to provide slides and demos of my sessions at SPC Adriatics 2014.

  • D1S3DEV - Lifecycle Management with SharePoint Apps and Solutions: slides.
  • D2S4DEV - Best practices with development of enterprise-scale SharePoint solutions: demos and slides.

As usual it was a great event, and I really want to thank Toni, Adis, and Nenad for such a well managed event. Well done guys!

Feel free to contact me - paolo(at)pialorsi.com or @PaoloPia - in case of need.

1 - 10Next
 
Visit my company: PiaSys.com 
 

 About this blog

 
About this blog

Welcome to the SharePoint Developer Reference Blog. I'm Paolo Pialorsi and I'm a senior consultant, author and trainer, focused on SharePoint development and customization. I'm based in Italy, but I work whereever it is needed (mainly EMEA). I'm a Microsoft Certified Master on SharePoint 2010.

You also can follow me on twitter: @PaoloPia

 MCM.png