SAML-login using the Java SDK

Hi Øystein Molnes,

There are actually a couple of ways to perform SAML Authentication via ShareFile.

The basic way is to perform a normal OAuth Authorization Code flow. The user will be directed to the ShareFile login page where they can choose to login via company credentials. This way, ShareFile's Identity Service will handle communicating to the Account's configured IdP, handling the SAML Request and Response, and will return to your application the normal authorization code which you can exchange for an oauth token. This is the "Web Authentication" which doesn't have documentation for the Java SDK but is the most common OAuth flow. We document the flow directly here: http://api.sharefile.com/rest/oauth2.aspx

If you need finer control or already have an integration directly to your IdP via SAML and so therefore have access to the SAML Assertion, then you can use the method you showed from the OAuth Service class. This will generate a token directly and utilizes the SAML 2.0 Profile extension grant located here: https://tools.ietf.org/html/rfc7522. This is commonly used when the application already has integration with their IdP and wants to embed Sharefile into their application without the user having to be directed to the Sharefile login. This can also be helpful if for some reason the IdP cannot redirect to ShareFile's ACS url.

The third option is what you specified from the Session Login documentation. However this does not use oauth and instead provides a session auth cookie to be used to calls to the V3 API, meaning you won't be able to utilize the normal OAuth flows like Refreshing tokens. Due to this, we highly recommend one of the other two options.

One thing to note, in all of these flows, the Sharefile Account must have SSO configured, so that we can do validation of the SAML Assertion. 

Please let me know if you need more information,
Dale

Actually upon further examination of the Session Login endpoint, it is not working in the way that our documentation states. It looks like it already assumes you have a Principal and otherwise just returns a 401. This looks to mostly be for Device registration, so the bit about SAML seems to be incorrect. I'm not sure if it used to work that way and no longer does, or if it was intended to work that way but never actually coded to work that way. 

Thanks for the quick and thorough answer, Dale. 

In our case we do not want to have some arbitrary user log in typing username and password. What we want is our application to log in using the same predetermined user and password every time, and we want it to happen automatically/programmatically. Hence, IdP-username and password for our user will have to be stored in our application.

Do you think we can achieve such an automatic login of a single user using some sort of web flow(figure 1), or will we have to programmatically obtain a SAML-assertion from our IdP, which we do not already have an integration to(figure 2)?

Is it a requirement then that the specific user must use SAML via the IdP? It seems like this would be a use case for the OAuth 2.0 password grant type. You could then store the specific user's ShareFile username/password in your application's configuration and generate a Sharefile OAuth Access token via the following call:

POST
https://subdomain.sharefile.com/oauth/token
form-url-encoded body:
grant_type: password
client_id: <your client id>
client_secret: <your client secret>
username: <configured sharefile user name>
password: <configured sharefile user password>

Even if the account has ForceSSO true, if the user is an admin, they can still log in via Sharefile credentials.

If they must log in via the IdP, then unfortunately the only way would be to programmatically retrieve the SAML assertion on your end and post the SAML assertion to the token endpoint using the "urn:ietf:params:oauth:grant-type:saml2-bearer" grant type.

Dale