Code-snippet for interoperability from Curl context - for example, could be from a Linux or MacOS workstation / server -, to Office 365 SharePoint Online; with service-based authentication by applying Active / Modern Authentication protocol handling:
#General variables
ProxyAccount="sa-curlAccount"
ProxyPassword="******************"
ProxyProtocol="http"
ProxyServer="xxx.xxx.xxx.xxx"
ProxyPort="8080"
SharePointCurlAccount="sa-curlAccount"
SharePointOnlineTenant="<URL of SharePoint Online tenant>"
UploadFile="<file to upload>"
UploadLocation="<URL of SharePoint Document Library>"
#Fixed variables
OUTPUT=${HOME}/Interop/output
TMP=${HOME}/Interop/tmp/spo
#the following steps are required to upload data from Curl context to SharePoint Online:
#
#1. Retrieve an authentication cookie to Office 365 through invocation of webservices
#1.a. (Optional) Step 0: determine the URL of the custom Security Token Service (STS) to next
# request a SAML:assertion for account identified by credentials
#1.b. Step 1: request SAML:assertion from the identified custom STS for account identified by
# credentials
#1.c. Step 2: use the SAML:assertion to request binary security token from Office 365
#1.d. Step 3: use the binary security token to retrieve the authentication cookie
#2. Step 4: Use that Office 365 authentication cookie in subsequent webservice requests to
# SharePoint Online REST API
#1.a. (Optional) Step 0: determine the URL of the custom Security Token Service (STS) to next
# request a SAML:assertion for account identified by credentials (outside datacenter, with proxy)
curl -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "login=${SharePointCurlAccount}&xml=1" https://login.microsoftonline.com/GetUserRealm.srf -w "\n" > ${TMP}/O365_response_step_0
#Extract requested STSAuthURL from response step 1
STSURL=`sed -n 's:.*<STSAuthURL>\(.*\)</STSAuthURL>.*:\1:p' ${TMP}/O365_response_step_0`
#Create input for step 1
File: O365_request_step_1-1
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc"
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<s:Header>
<wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
<wsa:To s:mustUnderstand="1">https://sts.<tenant>.com/adfs/services/trust/2005/usernamemixed</wsa:To>
<wsa:MessageID>b07da3ec-9824-46a5-a102-2329e0c5f63f</wsa:MessageID>
<ps:AuthInfo
xmlns:ps="http://schemas.microsoft.com/Passport/SoapServices/PPCRL" Id="PPAuthInfo">
<ps:HostingApp>Managed IDCRL</ps:HostingApp>
<ps:BinaryVersion>6</ps:BinaryVersion>
<ps:UIVersion>1</ps:UIVersion>
<ps:Cookies></ps:Cookies>
<ps:RequestParams>AQAAAAIAAABsYwQAAAAxMDMz</ps:RequestParams>
</ps:AuthInfo>
<wsse:Security>
<wsse:UsernameToken wsu:Id="user">
<wsse:Username>sa-curlAccount@<tenant>.com</wsse:Username>
<wsse:Password>*************</wsse:Password>
</wsse:UsernameToken>
<wsu:Timestamp Id="Timestamp">
File: O365_request_step_1-2
</wsu:Timestamp>
</wsse:Security>
</s:Header>
<s:Body>
<wst:RequestSecurityToken Id="RST0">
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
cat ${TMP}/O365_request_step_1-1 > ${TMP}/O365_request_step_1
echo "<wsu:Created>`date -u +'%Y-%m-%dT%H:%M:%SZ'`</wsu:Created>" >> ${TMP}/O365_request_step_1
echo "<wsu:Expires>`date -u +'%Y-%m-%dT%H:%M:%SZ' --date='-15 minutes ago'`</wsu:Expires>" >> ${TMP}/O365_request_step_1
cat ${TMP}/O365_request_step_1-2 >> ${TMP}/O365_request_step_1
#1.b. Step 1: request SAML:assertion from the identified custom STS for account identified by
# credentials (internal datacenter, without webproxy to outside)
curl -X POST -H "Content-Type: application/soap+xml; charset=utf-8" -d "@${TMP}/O365_request_step_1" ${STSURL} -w "\n" > ${TMP}/O365_response_step_1
#Extract requested SAML:assertion from response step 1
sed 's/^.*\(<saml:Assertion.*saml:Assertion>\).*$/\1/' ${TMP}/O365_response_step_1 > ${TMP}/O365_response_step_1.tmp
#Create input for step 2
File: O365_request_step_2-1
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<S:Header>
<wsa:Action S:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
<wsa:To S:mustUnderstand="1">https://login.microsoftonline.com/rst2.srf</wsa:To>
<ps:AuthInfo
xmlns:ps="http://schemas.microsoft.com/LiveID/SoapServices/v1" Id="PPAuthInfo">
<ps:BinaryVersion>5</ps:BinaryVersion>
<ps:HostingApp>Managed IDCRL</ps:HostingApp>
</ps:AuthInfo>
<wsse:Security>
File: O365_request_step_2-2
</wsse:Security>
</S:Header>
<S:Body>
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" Id="RST0">
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>sharepoint.com</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:PolicyReference URI="MBI"></wsp:PolicyReference>
</wst:RequestSecurityToken>
</S:Body>
</S:Envelope>
cat ${TMP}/O365_request_step_2-1 > ${TMP}/O365_request_step_2
cat ${TMP}/O365_response_step_1.tmp >> ${TMP}/O365_request_step_2
cat ${TMP}/O365_request_step_2-2 >> ${TMP}/O365_request_step_2
rm ${TMP}/O365_response_step_1.tmp
#1.c. Step 2: use the SAML:assertion to request binary security token from Office 365
# (outside datacenter, with proxy)
curl -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -X POST -H "Content-Type: application/soap+xml; charset=utf-8" -d "@${TMP}/O365_request_step_2" https://login.microsoftonline.com/RST2.srf -w "\n" > ${TMP}/O365_response_step_2
#Extract requested binary security token from response step 2
sed 's/^.*\(<wsse:BinarySecurityToken.*wsse:BinarySecurityToken>\).*$/\1/' ${TMP}/O365_response_step_2 > ${TMP}/O365_response_step_2.tmp
#Create input for step 3
cat ${TMP}/O365_response_step_2.tmp | cut -d'>' -f2 | cut -d'<' -f1 > ${TMP}/O365_request_step_3
BinarySecurityToken=`cat ${TMP}/O365_request_step_3`
rm ${TMP}/O365_response_step_2.tmp
#1.d. Step 3: use the binary security token to retrieve the authentication cookie (outside
# datacenter, need to pass webproxy)
curl -v -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -X GET -H "Authorization: BPOSIDCRL ${BinarySecurityToken}" -H "X-IDCRL_ACCEPTED: t" -H "User-Agent:" ${SharePointOnlineTenant}/_vti_bin/idcrl.svc/ > ${TMP}/O365_response_step_3 2>&1
#Remove DOS ^M from response step 3
cat ${TMP}/O365_response_step_3 | sed 's/^M//' > ${TMP}/O365_response_step_3.tmp
#Extract requested authentication cookie from response step 3 and create input for step 4
echo "Set-Cookie: SPOIDCRL=`cat ${TMP}/O365_response_step_3.tmp | grep Set-Cookie | awk -F'SPOIDCRL=' '{print $2}'`" > ${TMP}/O365_request_step_4
rm ${TMP}/O365_response_step_3.tmp
#2. Step 4: Use that Office 365 authentication cookie in subsequent webservice requests to
# SharePoint Online REST API (outside datacenter, with proxy)
curl -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -b ${TMP}/O365_request_step_4 -T "{${OUTPUT}/${UploadFile}}" ${UploadLocation}
exit 0
Alternative for the upload handling; interoperation via SharePoint API / webservice:
curl -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -X POST -H "Accept: application/json;odata=verbose" -d "" ${SharePointOnlineTenant}/_api/contextinfo > ${TMP}/O365_response_step_4_tmp
FormDigest=`sed -n 's:.*FormDigestvalue:\(.*\),.*:\1:p' ${TMP}/O365_response_step_4_tmp`
rm ${TMP}/O365_response_step_4.tmp
curl -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -X POST -H "X-RequestDigest: @${FormDigest}; X-HTTP-Method: PUT” --data-binary "{${OUTPUT}/${UploadFile}}" ${SharePointOnlineTenant}/teams/siteX/_api/web/GetFileByServerRelativeUrl('Shared%20Documents/SubFolder/${UploadFile}')/Files/$value
Great post. Thanks for sharing.
ReplyDeleteVery very helpful. Many thanks...
ReplyDeleteThanks for sharing! Very helpful, works great for me for federated login.
ReplyDeleteWhat is proxy in this case. I am trying to upload files to new SharePoint online site using ntlm authentication but facing unauthorised. I think the above code helps but I am not sure about the proxy . Can you please help
ReplyDeleteThis is for the reverse proxy, allowing connectivity from the Curl client deployed within internal company network boundary and protection, to SharePoint Online destination in outside location.
DeleteHi William. Thank you so much for sharing this. I work in a file transmission group and we found your script to be super-useful for uploading files to our cloud based SharePoint sites. However several weeks ago something changed and the script stopped working. We contacted the admins for our SharePoint sites and they assured us that 'nothing has changed'. :( The problem appears to be in this line of code which is not getting the response back that we used to receive. Any thought or help would be appreciated.
ReplyDeleteThe very first thing we send is an initial login request.
curl -U ${USER}:${PASS} -k -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "login=${USER}&xml=1" https://login.microsoftonline.com/GetUserRealm.srf -w "\n" > ${RESPONSE_0}
In the past the site would return an “STSAuthURL” in the response.
It would be enclosed between these two tags: and
That STSAuthURL would then be used in the next step to create a login Soap request.
Now the site no longer returns the STSAuthURL or the tags that identified it.
THANKS!
Hi Fred,
DeleteThe first step is to determine the URL of the custom Security Token Service (STS) used in the tenant of your organization. This is in fact an 'optional' step as the custom STS is fixed, and therefore also its URL. Only retrieve it once and store / remember it should be sufficient, however if you want to be flexible for changes then better request it explicit.
As for your organization the request to 'GetUserRealm.srf' all of a sudden no longer returns custom STS URL, I question whether either the user-account is still allowed to request the realm. Another cause would be a configuration change is made in the tenant of your organization to step away from using a custom STS aka from federated authentication, but that is highly unlikely as your admins stated 'nothing has changed'.
As alternative for the step 1 you can also use F12 / developer tools to determine the Custom STS URL; by capturing the network traffic while interactive logon yourself to your SharePoint Online tenant. The browser also applies active authentication via SAML.
Note: The pattern of the custom STS for organizations that have deployed ADFS is https://sts..com/adfs/services/trust/2005/usernamemixed
Hi William,
ReplyDeleteThanks for your response. Our support people opened a ticket with Microsoft who, like you, suggested a packet capture because they thought a firewall was blocking the response. Well before we got around to doing that, guess what? It magically started working again! We appreciate your consideration of our problem. We'll keep our fingers crossed that it continues to function. It's a great tools for us and others in our organization. Thanks again!
Hi William,
ReplyDeleteI know this post is quite old already, but we just migrated to sharepoint online. Must admit I'm not very clued up with Linux and struggling to get this to work. Firstly looks like MS changed their responses as I'm not getting a STSAuthURL tag in the response from them, seems it just changed to AuthURL, guess with bit of tweaks I can get it to work. My main question is if you can perhaps show me the correct CURL format without using proxy as we have dont need to use a proxy to get to ms online. Thanks Laurence
Hi Laurence, I am not an expert on Curl usage, but I suggest to delete from line
Deletecurl -U ${ProxyAccount}:${ProxyPassword} -k -x ${ProxyProtocol}://${ProxyServer}:${ProxyPort} -b ${TMP}/O365_request_step_4 -T "{${OUTPUT}/${UploadFile}}" ${UploadLocation}
all that is related to the proxy
Something like:
curl -k -b ${TMP}/O365_request_step_4 -T "{${OUTPUT}/${UploadFile}}" ${UploadLocation}
Hi William, me again. Thanks again for all the help in the past, everything has been working perfectly for more than a year now, and guess what last weekend everything stopped working. I checked with our company admins if there were any changes and they informed me they have changed from federated to managed. This now means I cannot retrieve even the first step anymore. DO you have any experience with getting this working on a managed domain? Thanks Laurence
ReplyDeleteHi Laurence, Managed Authentication exists in 2 types, Password Hash Synchronization (PHS) in which the authentication is handled by Azure AD itself; and Pass-Through Authentication (PTA), which relies on on-prem AD-DS (https://learn.microsoft.com/en-us/microsoft-365/enterprise/deploy-identity-solution-identity-model?view=o365-worldwide#managed-authentication).
ReplyDeleteIn case of PHS, you can find multiple how-to's on the internet. E.g. https://stackoverflow.com/questions/58827902/use-curl-to-access-an-api-secured-by-microsoft-identity-platform-azure-ad. Alternative is to authenticate via a ServicePrincipal, via OAuth2.0 (see https://learn.microsoft.com/en-us/azure/databricks/dev-tools/api/latest/aad/app-aad-token). That is also applicable / usable for PTA.
Than you William, back to the drawing board for me
ReplyDelete