Recently, I have been trying to create a C# application for SharePoint Online to import some data. After some digging on how to create the appropriate requests to the appropriate URLs for the appropriate tokens (phew!) discovered that the response back from https://login.microsoftonline.com/extSTS.srf was not what it was supposed to be (BinarySecurityToken was nowhere to be found).
After more digging, found this helpful post basically saying that you won’t/can’t get a BinarySecurityToken from an SPO site that was upgraded from BPOS. That kinda sucks.
STS responses differ between new SharePoint site and site migrated from BPOS
Here is the clip from the article for the sake of others:
Post replied on 6/25/2012 3:47 PM
UPDATE 6/25/2012…… I have spent a significant amount of time working with both the SharePoint Tech Support and business folks at Microsoft to achieve a positive outcome to this issue. A few things for you all to know.
First, currently there are two scenarios where you CANNOT export/import Office 365 SharePoint site templates because the SharePoint/site features do not match up properly.
1) Sites migrated from BPOS becuase they contain features in order for older BPOS sites to operate on Office 365
2) Sites exported using a higher plan (ie E3) to a lower plan (ie E1). You can only export/import from a lower plan (ie E10) to a higher plan (E3).
Second, There are two methods to connect to Office 365 SharePoint sites programatically:
1) Remote Client Object Model – This requires that a pop-up browser window appears where the user id and password are entered manually in order to connect to SharePoint. We have tested this code and it supports both Office 365 SharePoint sites orginally created in Office 365 and sites transitioned from BPOS. This works well if you are trying to create a utility to migrate your SharePoint data from an old site to a new site in the absence of being able to export/import site templates.
2) Headerless Authentication – This does NOT require a pop-up windows and you can only connect to Office 365 sites that were NOT migrated from BPOS otherwise you encounter the invalid security token error. There are a number examples on the internet that explain how to code this. We have tested them and confirm that it works. But, here is the kicker…. its is NOT SUPPORTED by Microsoft. According to what we’ve learned, support for this method is being decided upon internally but it isn’t looking like they want to do it for whatever reasons. I am in the process of escalating this via multiple channels. I would suggest you all do the same. Otherwise, developers will not have the ability to achieve SSO (without using ADFS) and you won’t be able to create automated applications that push data from external systems to Office 365 SharePoint by simply passing credentials. You should avoid incorporating this method into retail, production applications as it could stop working at anytime.
The problem is in step 2, we receive the improper response from the E1 Plan migrated from BPOS. While we get the appropriate result from my E3 account.
Note that in the conversation another person pointed out an issue with SharePoint sites migrated from BPOS.
(The developer is not getting the binary security token. Most likely a SharePoint site migrated from BPOS)
I hope that this gives you all some insight into a very frustrating issue.
Another person on Stackoverflow had the answer (http://stackoverflow.com/questions/9626539/saml-token-format) — just need to figure out how to implement it:
answered Mar 12 ’12 at 14:23
It’s an encrypted response using a KEK (Key Encryption Key). You’ll need the public key of the sender to decrypt the EncryptedKey. That lets you use that key to decrypt the CipherData which is what you’re after I would think.