We have a Sharepoint Project Management site up and is active amongst our clients. The site url looks like this:
https://projects.acme.com/clients/[client_name]
Each of our clients has to remember (or bookmark) this long url; the users of this site are not very savvy. They fumble with it all the time. We also do not want clients to know who each other are; so client 1 shouldn't know that client 2 is a client.
We would like to put a login form on our website, prompting for user id and password. Then we would like to be able to route the user based on a successful authentication, to the specific web that is theirs.
Is there a good clean way to make this happen? Is forms authentication the way to go? Are there drawbacks to using forms authentication?
Given my url structure, would this approach work?
http://msdn.microsoft.com/en-us/library/bb975136(v=office.12).aspx
Update: I'm not particularly interested in a solution that requires two weeks of effort on the part of a programmer/admin to setup, nor am I particularly interested in one of the commercial solutions that are $4k-8k. I was hoping to discover a pretty straightforward way to get this done in under a day of effort.
Yes, you can implement it using FBA.
However, if you use only the user ID and the password, the user IDs across all websites will need to be unique (i.e. if client 1 creates a john.smith user ID, client 2 will have to use john-smith or johnsmith or something completely different). The easy solution is to ask additionally for the company name on the login form, the user ID and the password, but then you'll probably have to handle different ways the users will enter the company name (i.e. acme, ACME, Acme, Acme Ltd, Acme Inc, Acme Inc.).
Update:
You can also consider host-named site collections and have URLs like https://client_name.acme.com. The downside is that you cannot use Central Administration to create a host-named site collection - you can do it by using PowerShell or custom code.
Generally it is highly unlikely you will find a free solution to get your task done in under a day of effort - admittedly, SharePoint does support FBA, but does not provide basic things like a login form, a change password form or user management; you need to create them yourself or use some existing solution (e.g. SharePoint 2010 FBA Pack).
If you want to separate users and also make URL's more sweet you have a two ways.
Create a web applications per user.
Create one application with multi tenancy support. Check more on this Spence's Harbar article.
Second approach is more flexible, but harder to implement, and if you plan to have many clients (more than 50) it's the only way.
Related
I was thinking of creating a voting app. The general idea is
browse a gallery
an awesome pic grabs your attention
hit the vote button underneath it
code magic happens
vote is counted
at a certain date, vote buttons become non-active and the app counts
the votes
This will be a web app, which means html5-css3-express.js-redis framework, or something similar.
How can I ensure that the user cannot vote for the same pic twice? By making him sign up? Huge procedure for just a voting app, dont you think? Plus, I guess I will also need a CAPTCHA thing to avoid unwanted, mass sign up.
But if I use coockies of HTML5 local Storage API, what is stopping the same user to clear his/her coockies and vote for the same pic again and again?
What is the best method?
Thanks alot
The most secure way is by using accounts to keep track of who has voted. Accounts are easy to implement in your application and you don't even need to hold the account data yourself if you use a service like Passport.js. You'll likely have a database set up already which makes it easy to keep account data as well.
The other method is to keep track of IP addresses but this has some issues (say, if a user uses a proxy). Also an IP address will cover all clients on a network means if one person votes on an image, all others will be unable to afterwards.
Easy way may be using npm package mongoose-voting where all logic for voting is already implemented.
There is also requirement for keeping track of users, so if you don't want a user to sign-up, you can automatically create a user by using the visitor’s IP address as the user’s ID.
There are many ways to manipulate vote results, but at the level you described, most of them are unnecessary.
well you dont need to build a login system these days as you can use any of the open id login authentication.E.g providers are facebook, google, yahoo and twitter.
I have a Spotify app and want to persist basic settings per user between sessions. I see the User object has a username field, so it would be easy to do this using my own backend. My question is, is this allowed, without requiring the user to log in, agree to some TOS, etc? Every app I see that persists any data requires me to log in with Facebook.
Usernames are typically obfuscated out in the Spotify API, so they're not the best thing to use. However, the anonymous ID for the user is the same for a given user/app ID combo across multiple machines, so you could use that instead. This sort of thing is what we designed the anonymous ID for, so you're good to go on the ToS front.
I can't find anything that restricts you from load/storing data from your own servers and I've seen 'you'd have to use your own server' suggested in a number of questions.
Not sure why other apps would involve FB - probably to get more info from the user or promote their product.
You should use the User's URI instead of their username though. I would expect it be more stable than the username and less likely to be little Bobby Tables.
I'm developing a web app that sends the user an email notification to complete a lesson/tutorial. I've added the ability to automatically login the user via the link in that email. This featured has been added to several services around the internet, most notable, OkCupid.
Here's how I've set up my table:
+----+-------------+-------------------+-----------+--------------+----------------------+
| id | key (22) | secret (40) | user_id | action | expires |
+----+-------------+-------------------+-----------+--------------+----------------------+
| 1 | IbQlQW8Dn...| hdC4dXQJUPA0... | 1 | lesson/14 | 2013-06-21 16:28:55 |
+----+-------------+-------------------+-----------+--------------+----------------------+
When a user visits a link via the email, something like:
http://example.com/go/IbQlQW8Dn8PNXJFFwHQxwh/hdC4dXQJUPA0pU7I6eUiXawbnobYv0iThA
[http:/example.com/go/key/secret]
The server first checks that the url isn't expired based on the date in the table. If it isn't expired, the user is automatically logged in using the user_id and then redirected to the given url in the action column. I used two separate values (key & secret) for the url just for added security (prevent fusking).
Now because of the nature of the site (video lessons), security isn't a huge concern, but I'd still like to know what best practices to consider.
Should I limit the number of times a link can be used?
Currently I have the link expire 60 hours (3 days) from when the
email is sent. Should this be lowered?
Obvious two risks for unauthorized access include someone forwarding the email or someone gaining access to the user's email account. Anything else to consider?
Thanks for everyones insight, if this should be moved to another section of StackExchange, please let me know. I know I've seen other best practice post on here in the past.
Sending an auto-login link is fairly similar in risk to sending password-reset links in email and lots of sites do that.
This is a judgement call that you have to make. There's not a shared decision matrix that people use to decide what is and isn't an acceptable risk. What you're making here is more of a business decision, you're weighing the security risks versus ease of use (which can translate to more users and more business).
You need to ask the question 'What's the absolute worst thing in terms of site availability, business reputation and user experience that can happen if this feature is mis-used?'.
Additional things you should be concerned about:
People plucking your auto-login links of off of shared wifi networks
Auto-login links ending up in the logs of proxies between your server and the client
I recommend making the links single-use only or keeping the expiration time low. You should also put in monitoring that will alarm if a link is being overused.
You should also make sure you're not vulnerable to SQL injection when you take the secret and query the DB.
I pretty much agree with everything u2702 said in his answer, but you should also consider not allowing the user to change their password without confirming their current password if their current session was created from any form of autologin (cookie, link etc.). This can at least protect the user from getting locked out of their account by a changed password.
I think you’ve got all of the important stuff. I’d agree with everything #u2702 said and just add…
You might want to give users a way to invalidate their outstanding login links, or invalidate them automatically when they change their email address or password.
If the site sends out a lot of email, you can skip the database and encode the user, target, and expiration in the URL along with a signature. Amazon supports this for temporarily granting access to objects in S3 (http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html) and other sites use it for CSRF tokens. Pseudocode:
params = encode_qs(userid=1, target="lesson/14", expires=…)
url = "http://example.com/l/?" + params + "&" +
encode_qs(sig=hmac_sha1(secret, params))
(The secret you use to sign the request doesn't have to be unique per-email since it's not revealed.) This is no better than generating random keys, like you do, if you don't mind the load.
I don’t think you gain anything by limiting the number of times a link can be used before it expires (OkCupid doesn’t, some people hold onto the most recent email and use it more than once).
Does a separate “key” and “secret” give you any real extra security if they’re always used together?
I'm sure there must be a simple answer for this but I can't figure it out -
I have a Silverlight 4 OOB application that requires a login screen/security. The View shows a LoginView (Username/pw) which then passes the details to a WCF service and checks it against a database. It will return a result to the client to say if their details were valid or not. This part works fine.
Where I need some guidance is the best way of storing the fact that the user is logged on/authenticated for the current Silverlight session.
It's OOB so we can't use any web cookies/session stuff as far as I know. I assume we have to store some sort of Identity in the thread but I need some pointers please.
The other caveat is that I would like to secure all other pages to check if the user is authenticated and redirect to the login screen if not. I use the Navigation framework so I have a Frame - this may make it easier...
Any tips or pointers appreciated - I just need some ideas to get started please.
Just store the fact that the user is authenticated anywhere you like - I tend to like the Application object since it's an app-wide setting, but you can stick your "IsAuthenticaed" and/or "Roles" properties anywhere, really.
Take a look at WCF RIA Services - even if you don't want to use their solution, you can take a look at the generated authentication code it makes and see a good real-world example of how this can all work.
As for redirecting if the user is not logged in, I suggest using an INavigationContentLoader on your Frame, which can implement this logic in a central location. See these two excellent posts by David Poll on the subject of INavigationContentLoader and authentication/authorization:
http://www.davidpoll.com/2010/01/01/opening-up-silverlight-4-navigation-authenticationauthorization-in-an-inavigationcontentloader/
http://www.davidpoll.com/2010/05/10/common-navigation-ui-and-authorization-driven-sitemaps/
Here's the scenario:
You have two seperate websites that exist in different environments (I.E. different databases, different web servers/domains)
You have full control over the code for both sites, but from the above point, they can not directly communicate with each other's database
You must transfer user from site A to site B securely
What is the best way to implement this? Simply sending the user identifier between the sites via query string wouldn't be secure, even if encrypted, since someone else could obtain the URL. It seems like the standard solution is to pass the user identifier along with another temporary key that web site A created, and web site B knows about. If this is the case, what's the proper way of securely setting up the system with the temporary key?
Thanks!
I am doing something like this. The best thing I can think of right now is passing a HASH of the user ID, or if that makes you worry, the hash of some other user data.
If yuo want temporary keys(I might do something like this too), how about setting up a web service on A that B can call to to get the user ID based on the temporary key. This way it's a totally separate call, and can be secured.
Take a look at "Pass-through Authentication," its a concept that allows a user's identity to be passed from one system to another.
Additionally, another idea that you may want to try is to create a secure token that does not expose the user's information and pass it on. However, this requires both systems to have similar data to verify the token. As the other answer suggested, hashes are very good uses to create non-descriptive bits about sensitive information.
Write a web-service call over HTTPS, at both ends, to retrieve the users details, and that only works for a specific login-pair. Problem solved. You need to make the login-id's at both ends uniform or use single sign on cookies. More details in the paper by Vipin Samar: "Single Sign on Cookies for Web Applications".
They can't get the URL/Passwords unless they go into the application code at one of the servers.
You need to pass information between Site A and Site B, but you don't need to make the user the conduit for that information.
Site B could have a web-service that allows Site A to create a session for the user. In this design the interaction would go as follows:
User clicks button on Site A
Site A calls web-service on Site B which passes a temporary login URL back to Site A
Site A redirects user to the temporary URL on Site B