5

Illustration : mainsite.com and contentsite.com both are being developed for same company by two teams. we will have login etc at mainsite.com contentsite.com will have some content that is not available for users who have not non logged. But login will be via mainsite.com What is the best way to implement this? Some users might be on http, we want them to be redirected back the http page they were on, if they click login. Besides that we need contentsite.com to know that a user had logged in and what ther id is.

There will be a seperate on register and on-profile change job that shares information from mainsite to contentsite.com

So the question is : is encrypted user name enough (after login to tell content site that user has logged in? add random salt so it cant be spoofed?) 2. need webservice so contentsite can cross check login?

We are considering :

  1. Redirection on login so we touch the 2nd site and allow it to place http and https cookies. Is this what google does (but only https) for youtube and other google sites? Or a combination of web services domain to domain calls in the background? Do we need API calls to stop man in the middle or is initial SSL enough? Finally we want to be able users to use most of the website in http or https besides the checkout, login and profile pages.
  2. javascript add on for the content domain, with AES encrypted user name along with some hash. So no redirection but everytime we add content tag we pass encrypted authenticated user or anonymous of not yet logged in
  3. oauth or auth0.com or other scheme, not sure if we need this as we are already using a world class spring security impl built by a big co and just want to share our login user id with other domain that is our own

Looked at a few question about the same thing like this node js question but they did not seem to fit exactly. Is there a standard we have missed?

We are using spring security for the main store. The content site will have no data base but we will share some profile information via separate non web channels (on sign up and profile change api calls).

For login the store website has SSL pages ready, that redirect you back to the original page (http or https).

Improve this question
2
  • Is the query clear now? Would appreciate a pointer or two security folks?
    – tgkprog
    Jul 29, 2014 at 7:12
  • "Encrypted" user name would never be considered enough without regard to salt. Far too easy. OAuth may be your best option but only if you restrict the servers to a select few who are known secure.
    – Jeff-Inventor ChromeOS
    Aug 22, 2014 at 7:35

2 Answers 2

Reset to default
5
+50

I think OAuth is your best bet; specifically OAuth2. It might be a little overkill, but it does what you want.

OAuth

OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner.

What does this mean? You have a client application, contentsite.com, that you would like to give secure access to through mainsite.com. User registration should already be implemented. The contentsite.com will redirect to mainsite.com for login, and provide a mainsite.com access token to contentsite.com. If the user logs out the token becomes invalid, and if it's used it should redirect back to login.

contentsite.com would register with mainsite.com as an application and receive a secret value as well as a client ID. The client ID is used when requesting a token. Access tokens are used for any other resource access once granted. High-level overview of OAuth2.

To accomplish all this you'd need to implement an OAuth provider on your main site. Here's a step by step with some server code written in Python using Flask. Client side implementation is pretty simple. Given the client ID and secret you make a request to your OAuth provider for a token. Here's a link to a nice little Python library, you can declare the redirects right there client side. You would just replace the Google specific links with your site specific links.

Like I said it might be a bit overkill, but it does exactly what you want. If you wanted users to be able to login with things like Facebook or Google+ or whatever then the functionality is there. Also, OAuth2 standard requires SSL/TLS to be used for its requests. Always a plus.

Spring Security

Spring Security OAuth - Main Page
Spring Security OAuth2 - Developer's Guide
Spring Security OAuth - Github

Conceptual Examples for OAuth (non Spring Security)

How to Implement Safe Sign-in via OAuth - This link focuses on using Facebook, Google+, etc as a basis for registration/login. If you wanted to support that.

Some notes on implementing a Node OAuth2 Server, from Papers.

Here's a good resource for OAuth libraries for different languages, server and client side.

OAuth2 RFC - If you like reading RFCs

Improve this answer
2
1

If you have HTTPS setup for your login pages there's hardly a valid reason why you wouldn't keep it up throughout the whole website. If a user visits a page unencrypted with a specific session ID/token, what prevents a spoofing adversary from stealing that token and then visiting the website as well?

And it's not just a matter of the token being observed, but also the fact that you can't tell which of two HTTP requests with the same token is "legitimate", whilst you can tell that when you have an existing encrypted connection associated with a session token you don't expect another SSL session to be started somewhere else and the other end of that session sending over an existing session token.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .