Good day.
So ive been reading on how it is bad "practice" to set a SharePoint applications trust to full. Due to this hackers are able to infiltrate you web app. what if though there are pages or web parts that require full trust to function correctly?!
In my case i want to elevate the trust on a coded application page and maybe a custom web part. Are there any ideas on how one would go about doing that in code?
Your help will be much appreciated.
Use SPSecurity.RunWithElevatedPrivileges() method to run any code in your application page with elevated privileges for unprivileged user
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(web.Site.ID))
{
// implementation details omitted
}
});
It is important to create new SPSite object and SPWeb object inside delegate. Do not reuse existing SPSite object and SPWeb object because they are created with restricted permissions
Related
Am new to external logins in coding, so have started to get my head around the concepts but am still running into some issues.
Effectively there are 2 sites, both hosted on the same server, and as I load one up (Lets call it MySite), it should redirect to the second Site (Lets call it LogOn), where a user can logon using their credentials. LogOn then redirects back to MySite, with the credentials which can be used to see if they have the credentials to view this site, and shown messages or data dependent on their permissions
However right now, I can get it to redirect to LogOn. I've been experimenting getting it to redirect to Microsoft login and Google also, which redirects fine, but when I set up a WsFederation and add it to my authentication services I'm not quite sure what information to put in the Wtrealm section and metadataaddress options. Hopefully I have given enough information for someone to understand where I'm running into issues.
My code is shown below
services.AddAuthentication("MyCookieAuthenticationScheme")
.AddWsFederation("TestWs", WsOptions =>
{
WsOptions.Wtrealm = "http://SiteOnServer??";
WsOptions.MetadataAddress = "???";
WsOptions.RequireHttpsMetadata = false;
})
Any help would be greatly appreciated, just couldn't find a great deal of documentation taking you through the process.
Thanks in advance!
First of all, I am trying to retrieve decent webinfo of my web application however I received Access denied error and the error is coming from site collection “sitemaster-a118466c-660d-479c-873f-af6284910724” as screen shot below
I never create “sitemaster-a118466c-660d-479c-873f-af6284910724” as my site collection, so I suspect it is bundle with “Publishing” template.
Below is the sample code that I use to retrieve my decent webinfo, and I have my access denied error here.
SPSecurity.RunWithElevatedPrivileges(delegate ()
{
using (SPSite site = new SPSite(SiteCollectionUrl))
{
//code to retrieve my web application decent info
}
}
Once I face this I wanted to update ““sitemaster-a118466c-660d-479c-873f-af6284910724” site collection administrator users however I cannot find it from sharepoint centraladmin site.
I have used asp.net membership for some time, but this time due to certain requirement we cant use asp.net membership. So i have to implement a simple login system where we have to validate uses and give them access to website section and on other side also block access to certain folder also so that logged in users can only access contents of these folders.
block access to following folders
/English/
/French/
/Images/
User should be able to access contents of these folders only if they are logged in. I am setting a simple session variable when user logs in successfully. Let us session["UserLoggedIn"] = true.
With asp.net membership we can block access to folders from web.config. But i am not sure how i can do it with custom loggin.
Any pointer in this regarding would be help full.
I'm not too sure if this will work for you, but I have done something similar to this in the past (see user Isaac's answer for a bit of guidance): Securing a web folder with out membership roles defined
Basically, upon the login event you could assign the session a variable of "English" or "French" (note I'm not in VS right now so my code might be roughly what you're looking for):
void protected OnLogin()
{
if(UserIsAuthenticated)
{
Session["English"] = true;
}
}
and then in the Global.asax file you should be able to reference that variable if the user is authenticated:
void Application_BeginRequest(object sender, EventArgs e)
{
if(Request.PhysicalPath.Contains("English")
{
if(!((bool)Session["English"]))
//Not "English" user - redirect to login or unauthorized page
}
}
Again, my code is mostly taken from the link I gave you, if that doesn't work I can fish around some of my projects to see exactly what I've done in the past.
Additionally you could use Visual Studio 2012 and use the ASP.NET Web Configuration Tool and try to work your user database into working with it, I've seen people do it - it is a bit complicated because you have to code a bit in the web.config file, but is more likely secure I am guessing. This MSDN article might help some as well: http://www.asp.net/web-api/overview/security/external-authentication-services.
Thanks for reading and for your thoughts; this is a hairy problem, so I thought I'd share to see if it is actually a fair challenge for more seasoned developers than ourselves.
We're developing a web application for a corporate Microsoft Active Directory environment, and we use Windows Authentication provided by IIS to authenticate users for single-sign-on, alongside Forms Authentication. I know IIS complains when both are enabled, but it works very well, and every site we've deployed at has had no weird quirks to work around - until now.
The new site has "shared" machines, logged in permanently with a generic account that has read-only access to the applications they need to use. This means that we can't differentiate between users who should have different permissions to the application; we need some way of prompting the user for authentication details.
First try was some serious googling; nobody else in the world seemed to have our problem except for a few misguided souls who had asked questions into the ether and received no response.
After a bit of brainstorming and nutting out the way IIS's authentication works, it seemed that the most straightforward way to approach the problem was to issue a 401 Unauthorized in response to a user known to be a shared account. Initial tests here seemed fruitful, yielding successful changes of username inside the browser, however a prototype at the site did not prompt for credentials, and the browser kept the same account details. We also hit on the IE-specific javascript
document.execCommand("ClearAuthenticationCache")
which, again, worked in the lab but not onsite. Further experiments with IE security settings onsite revealed that the browser would automatically reauthenticate if the webapp site was excluded from the Intranet Zone, regardless of the method used to trick the browser into prompting the user for new account details.
Now we're stuck. We've got workaround options for getting it going on time, but they're definitely not the "right" answers:
require users to log out of the shared account before logging into our app (...yuck)
exclude our webapp from Intranet Zone on all machines
provide a non-SSO login service for users
I'm convinced that there's a canonical way to do this - a known pattern, a common base problem that's already been solved, something like that - and I'm very interested to hear what sort of inventive methods there are to solve this sort of problem, and if anyone else has actually ever experienced anything remotely like it.
We ended up settling on a solution that submits a query to the LDAP directory the server knows about. It means having to accept the user's password, but no other solution was solid enough to run in a production environment.
Hopefully this helps someone. .NET Framework 3.5+ required.
using System.DirectoryServices.AccountManagement;
private static bool IsLdapAuthenticated(string username, string password)
{
PrincipalContext context;
UserPrincipal principal;
try
{
context = new PrincipalContext(ContextType.Domain);
principal = Principal.FindByIdentity(context, IdentityType.SamAccountName, username) as UserPrincipal;
}
catch (Exception ex)
{
// handle server failure / user not found / etc
}
return context.ValidateCredentials(principal.UserPrincipalName, password);
}
Could you not create a page to which the shared accounts are denied access. Then do a redirect to that page, with a return URL encoded in the query string, at any point where you need the user to reauthenticate with a non-shared account? This should trigger the browser to put up the usual login dialog.
After the user reauthenticates, the new page should just redirect back to the return URL in the query string.
I am having trouble doing something simple like the following
using (SPSite site = new SPSite(topLevelSite))
{
SPWeb rootWeb = site.OpenWeb();
SPWeb newWeb = rootWeb.Webs.Add(siteName, "abc", "abc",1033,template,false,false);
}
But the catch I am trying to add a site to a PKI enabled sharepoint site:
This code works fine when I am dealing with my non pki sharepoint server, but I get the error:
"
The Web Application at https://server/sites/newSite could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system admin may need to add a new request URL mapping to the intended application.
"
My main question is: How do you go about accessing with C# a sharepoint site that is PKI enabled? Do I need to insert my certs somewhere programmatically or what?
Are there steps before I open SPSite, or are there other Objects I need to use that are more PKI friendly?
I would first make sure that the URL you use is the same URL SharePoint itself knows about. This thing is called Alternate Access Mapping and is accessible through the Central Administration. Sometimes people would map the web application to a different URL using DNS and IIS configuration only, without updating SharePoint itself. It might appear to be working correctly when browsing the site, but this kind of error would appear when using the API