Forum Discussion

adamyocum's avatar
adamyocum
Contributor
11 years ago

Calling Modify or Create REST API methods from external domain - Authentication Options

I am working to develop an interactive user interface that will allow our community users to read and reply to posts from certain boards in our community without leaving one of our other non-lithium based sites.

 

The community site is community.company.org and the site the user will be posting and reading messages from is travel.company.org with potentially more sites to come. (not real domain names)

 

First a little about our setup. We are using SSO. I have already requested and confirmed that CORS has been enabled on our community servers to allow cross domain calls from the various domains that will need to call the REST API methods to create and reply to messages in the community. I am able to do cross domain calls to get messages with no problems using anonymous access, I have confirmed this by writing a small jQuery library that is calling the community API.

 

I was hoping that once a user was logged in using our SSO that authentication would be handled by cookies set during that process. I've read just about every authentication post on this site, and from what I understand, cookie session authentication is not enabled by default for the REST API. Plus through testing and further reading the forums, I've found that even if we did have this enabled I'm fairly sure the user would first have to go to the community site first before the session cookie authentication method to work. Our users will most likely not be doing this. They will go from a login.company.org site that handles SSO and then be sent to travel.company.org where they will need to be able to interact with the community.

 

My question is should I forget about using cookies to authenticate? Is the SSO Token method the way to go? Our login.company.org site is already generating one of these SSO Tokens for community site signon purposes, so it seems like a logical place to put a service to get addional Lithium SSO Tokens on demand.

 

Since these tokens can be used only once and the session keys that you get can timeout, that is why I am thinking creating a web service I can call to get the SSO Token on demand is a good idea. My idea is that on the external site we will check to see if the user is signed into the Single Sign on for our site. If so, I will ask this new webservice for a SSO Token for lithium. Then I will use that to get a session key to use. If the key stops working I can ask for a new token get a new session key and keep going.

 

This seems to be the only way to both not require the user to visit the community site before being able to post to it and also not require opening what was described as a potentially security risk of allowing cookie session auth in the REST API.

 

Any advice or possible warning of pitfalls with this type of integration would be much appreciated!

 

Here are some diagrams showing what I'm picturing for the web service and the JS flow for getting session keys etc...

Get SSO Token Web Service Flow

Community Post/Reply via API JavaScript Flow

 

lithium community sources that seem to suggest the cookie authentication for REST API might be possible but also not advisible:

From REST-API-Security-Best-practices-advise

"Lithium can configure your community to allow a user to automatically authenticate to the REST API using the session cookie that gets set when they authenticate through the web ui (talk to your CSM about turning this on if you want)."

 

From Calls-to-modify-methods-are-not-allowed

"This is configurable, though we typically discourage enabling this in production for security reasons. If you're interested in pursuing this further, I would suggest contacting Support as you mentioned."

 

5 Replies

  • JakeS's avatar
    JakeS
    Lithium Alumni (Retired)
    11 years ago
    Just a quick question; have you seen the authentication page under Community API? http://community.lithium.com/t5/Community-API/bd-p/developers-rest-api?page=authentication
    This should mostly have the info you need for this; basically you can pass your sso token as a query param into an authentication/sessions/login api call and get back a REST session key that can be used subsequently to authenticate rest calls. By default this session key will last at most 24 hours, and will expire if it is unused for 30 minutes, but these values are configurable, you'd just need to open a support ticket to get them adjusted. Your diagrams all look pretty good generally, hopefully this info helps getting your service set up. One thing to note is that your login metric will be incremented by the authentication call I mentioned above; I assume this is acceptable and that the important part is that users don't have to hit a community page to authenticate, but it's worth noting.

    Btw, I think cookies would not meet your use case because you would need to hit a community page to get the required cookie, and as noted they aren't the best solution for other reasons.
  • adamyocum's avatar
    adamyocum
    Contributor
    11 years ago

    I had read the authentication document you mentioned, from it I was 90% sure I needed to use the SSO Token / session key auth method, but wanted to rule out the cookie authentication option. Also, in my situation creating the SSO Token meant requesting a new service to be exposed by our SSO system, coded by a different department than mine. I'm confident now that cookie auth is not an option for my use case. I've started working with our other developers to design a secure service to get Lithium SSO Tokens for authenticated users. Since they are already generating tokens for the standard SSO login authentication cookie, it shouldn't be a large undertaking.

     

    I've started building a javascript library to authenticate and communicate with the rest api, and things are looking like they should go well.

     

    Thanks for mentioning the login metric thing. I will keep that in mind, keeping careful not to authenticate / re-authenticate unless needed to cut down on that.

     

    Thanks again for your advice!

  • JakeS's avatar
    JakeS
    Lithium Alumni (Retired)
    11 years ago
    Cool, definitely ask any questions that come up while implementing this, I'll be watching this thread.
  • I was under the impression that if you made a call to the REST API authentication method with the SSO cookie (but not specifying a username or password) that it would authenticate with the SSO cookie and return a valid token that can be used in subsequent calls. This avoids the for the user to browse to the community first.

     

    I've just tested this and seems to be working. However, it could just be that the 'unsafe' cookie authentication is enabled.

  • JakeS's avatar
    JakeS
    Lithium Alumni (Retired)
    11 years ago
    Yeah, that's the correct flow, and doesn't rely on a browser session cookie; that token should work if you add it as a query param to an api call in ANY context, even outside of the original browser.