Authentication via OfficeCRM 365
SharePoint Online uses Claims based Authentication and to authenticate via Java application is not documented enough. Initially Wictor Wilén’s tutorial is a nice help in implementing it in .Net framework. It allows to analyze the request and response going through application and Claims based Authentication through Fiddler S/w . The actual Hard Work begins while implementing it in JAVA, since java has different API’s and supporting classes.
Going step by step , SAML request needs to be populated with credentials as well as the Application URL replacing with the EndPoint mentioned in the sample SAML xml . Then it requires sending SAML request to the STS site https://login.microsoftonline.com/extSTS.srf. It’s easy to make this request vie simple java code like the following code shown below.
HttpParams params = new BasicHttpParams();
params.setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, 180000);
HttpClient client = new DefaultHttpClient(params);
HttpPost post = new HttpPost(url);
StringEntity entity = new StringEntity(soapEnvelope);
post.setHeader(“Content-Type”,”application/soap+xml; charset=UTF-8″);
post.setEntity(entity);
response = client.execute(post);
It Uses Apache HTTP core and client jar files. Be careful in setting the Content- type to “ application/soap+xml”. It will return the response xml containing security token if credentials found to be matching , else response will indicate “Invalid User”.
After getting the Response XML having the Token, One has to parse it to get the Token which is surrounded by
< wsse:BinarySecurityToken>t=……
One must always keep the whole token along with “t=” . SAX parser was used to parse this XML. After getting this token, It should be sent to the Application URL given in SAML request which should append “_forms/default.aspx?wa=wsignin1.0” at the end. If token is validated by SPO (application URL) two Cookies (FedAuth and rtFa) are returned.
For E-Accounts , User-Agent should be added “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)”. Request Content Type used was “application/x-www-form-urlencoded”.
This Request for cookies may be redirected , hence one should always verify the status code (301) and returned Location URL via Header response in the first request and call that URL again with the Security token sent again. I did it Recursively by looking at the status code (301) and getting the Location from header in the response, since Location is returned in the header if request gets redirected. Following code will show the logic.
if(response.getStatusLine().toString().indexOf(“301”)!=-1){
System.out.println(response.getStatusLine().toString() +”\n Redirecting to new Location “);
for (Header str : response.getAllHeaders()) {
System.out.print(str.getName()+” “+str.getValue());
if(str.getName().indexOf(“Location”)!=-1){
String newLocation = str.getValue();
return getCookies(newLocation,token);
} else {
return null;
}
}
}
Here’s a Microsoft Dynamics CRM & Intacct Integration Demo:
If you liked the article, share it in your favorite social media!
