I have been tasked with creating a SharePoint 2007 webpart that logs the user directly into our website (which uses forms authentication). Most likely the username and password will be same in the SharePoint account as in our website.
Ideally we would like it to be fully integrated in that the webpart looks up the SP login & password, somehow encodes that using SHA1, MD5 or similar encryption, then passes that along to our login page on the query string. However given we have little experience with SharePoint, and that it's probably impossible to programmatically access the SP username/password from a webpart we realize this isn't very likely to be possible and if so would probably require a lot of development time.
Another option would be to load a login form from the website within an iframe in the webpart, which would show the login & password first but store a "remember me" cookie after the first login, and on each subsequent load display just a button that logs them in directly using the cookie.
Has anyone done something similar before? I'm in over my head, any guidance would be much appreciated! :)
A good login system doesn't allow retrieval of passwords at all. (Forgot your password? Prove you're you and we'll reset it, send it to you, and force you to change it to something we can't see once you're back.) This way you CYA against both Angry IT Admin Guy back-dooring his way into other user accounts when he's disgruntled over coffee pot politics as well as a potential attack vector for the Internet at large to exploit.
The cookie idea is plausible. Depending on your SharePoint/other website configuration you may be able to federate your logins to a single authentication provider (using ADFS, Passport, OpenID, etc.), which would be a more elegant solution, but may not be feasible in your scenario.
If you're using SPS 2010 and your other website is based on .NET, then Windows Identity Foundation would be a option.
Related
Hey Guys i just quickly wanted to double check – as far as i know there is no way to implement the Microsoft Azure Login into an existing Website / Style – is this correct or is there any kind of work-around?
It really is annoying that customers need to "jump of" our page to azure to login in.
You can choose e.g. the background image. But, of course you can do the authentication back-end yourself, using the Microsoft Authentication libraries. See here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios
We have a SharePoint 2010 extranet web application that uses claims authentication.
The Intranet zone is using mixed authentication (NTLM against internal AD and FBA against a separate AD).
The Extranet zone uses FBA only against the separate AD.
We have sites that have NTLM users in the Members SharePoint group. We have librarys with "Person" colums limited to the Members group. We would like to allow FBA users to pick NTLM users that are in the Members group when fillng in item metadata. The problem is that the FBA users can see the NTLM users in the people picker but when they select them, the user is not resolved. I realize we could probably work around this by adding NTLM to the Extranet zone but prefer not to do this if possible.
My questions are:
Is this a scenario where a custom claims provider would be appropriate?
Is this a problem that could be resolved with the peoplepicker-searchadforests property? (I've not been able to get my head around a real world example where this property is in play)
This is how I understood that the people picker works. I'm not 100% sure so don't take it for absolute truth :)
Basically, in the context of the Extranet application, all standard pickers are completely unaware that the internal AD exists. The "hits" you get in the people picker are found in SiteUsers list and/or profile database.
"Is this a problem that could be resolved with the peoplepicker-searchadforests property?"
I don't think so, I think that even if you are able to make the people picker search other ADs might give some pretty weird results, like being able to add a persons permission to some object, but with the FBA claim prefix, which does not equal the user when logged in using NTLM. (A user signed in with NTLM and Claims is technically different users.)
"Is this a scenario where a custom claims provider would be appropriate?"
I don't think so :(
One trick that you can do for people picker that YOU create (i.e. you have a custom page or webpart or something with a people picker), there are several properties you can set to change from where the users are retrieved. For example you can set a property like "WebApplication" or similar that basically make the picker work as if in the context of the internal application despite the current user being logged in on the external app.
What I'm thinking is maybe there is some way to enable the NTLM membership provider on the extranet application, but without actually enabling end user authentication with it. It doesn't sound impossible but I'm not sure exactly how that would be done though.
I have somewhat of an odd question (for me, at least).
We have some private information a department would like to place on our SharePoint farm. The problem is, this is very sensitive information, and law demands that we have a 'two-stage' login process to secure the data.
Currently, it is housed using a system that:
A) you have to login to our network (windows logon screen)
B) you have to login to the application.
Our SharePoint farm has integrated authentication enabled. Meaning, once you login to your computer in the morning, you never have to login to sharepoint as it already knows your credentials.
This is a problem for us. Can we enable some sort of custom Sharepoint login?
Will this require a new web app for the site? A new site collection only perhaps?
Thanks,
~~Kolten
What you are looking for is called forms based authentication. Sharepoint 2010 uses claims based authentication and one of the providers you can configure is forms based. Meaning they provide a user name and password.
Here is a tutorial with the steps to do, it is a relatively straight forward process. just follow all the steps.
http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
If you move you site out of Intranet zone, then IE will automatically ask for credential everytime.
See this:
http://support.microsoft.com/kb/258063
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
As already said above:
The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.