Freeware – SharePoint Security Scanner

Just want to the app?

Download here: http://spsecurityscanner.codeplex.com

I recently was at a client doing an audit on the SharePoint environment, and the question of how to do continual scanning on the site for possible system/ web service / and list WebForm exposure. Mimicking and automating this behavior is no big deal, since you are essentially just dispatching requests to various static URLs. The SPList object SPFormCollections can be exposed through the SPList.Forms property, and via web services rather than using the Forms web service you are sorta relegated learning on the SPList content type methods to get access to all customized forms. The SPWeb related ones are better to keep in a mutable file that can be managed.

So da da da! Here is a simple SharePoint security scanner. The composition of the application is actually pretty straightforward; it’s only about three forms. To abstract SharePoint explicit reference requirements the OM and web service assemblies are dynamically loaded at runtime so that SharePoint references are only required when doing OM connection types. Web service ones it shouldn’t really matter.

There are about three steps to get it going:

Start the application:

Click Open Connection:

And choose the connection type, and credential specifications:

When done hit connect, and you will return to the main form. Fill in whether you want to iterate SPList objects:

You can manage the web related urls, since the SPFormCollections are automated, through the Manage Web Inclusion List:

Scan the site, then you can view the results:

 

So it’s not very fancy, but gets the job done. Have hacky SharePoint fun!

 

Share

Quick Tip: Cross Domain Policy Problems With Web Services / Silverlight

More a note to myself more than anything. If you have a Silverlight application that is invoked from a domain and then making calls to a SharePoint web service in a different domain, you may encounter the following error:

An error occurred while trying to make a request to URI ‘http://sharepoint/stuff/morestuff/superservice.svc’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.

The fix is to place copies of the crossdomain.xml and clientaccesspolicy.xml files in the root application folder. Works fine afterwards.

Share

SharePoint Claims Based Authentication Architectures Explained Part 7 Transforming Identity In SharePoint

The role of the issuer involves taking the incoming identity and making it into a secure token that can be used for a given application. The token is very similar to a boarding pass it has pertinent information about the identity of the user. The only information that is on it is what the application needs. This is why such boarding passes often have a role that can be used immediately. This is faster that relying on Windows groups.

The issuer is often thought of as an identity transformer. It is able to convert the incoming identity into something that is readable to the application. There are users that can have one sign on credential that allows them to access all of the different application they may need. This is because there is an issuer in the realm with the trust to authenticate all of them.

There is a local issuer that offers claims to applications in their own realm as well as to those that are in others and need access to multiple applications. It allows them to use their local applications and those that are remote all with just that one credential being in place rather than needing one for each of them.

The Active Directory Federation Services (ADFS) relies on a rules engine that will support the claims transformation. They have a set of rule in place that say when a claim of X type is make with X as the value then issue this type of claim. For example you may have an application called Managers that allows special access to certain features. This claim will take that user to a Mangers group in the realm. That is where they will always be sent.

A partner group may have a group called Supervisors that needs to gain access to that Mangers area in the application. Through the transformation process both the Supervisors and the Mangers can access it as long as the issuer has trust for this to be acceptable. This is all possible due to the way in which the rules are written in the ADFS. The issuer has to be designed to support these types of transformations because the terminology used in each company can be very different.

Hopefully you now see what is possible with the concept of cross realm federation. Here are the steps involved with a browser based application:

  • A user in a remote realm clicks a link that will take them to your application
  • That user is redirected to your local issuer
  • The issuer redirects the users browser to the issuer that is in their realm.
  • The local issuer authenticates a token, sending the user’s browser back to your issuer with the token
  • Your issuer will validate the token, transform the claims, and then issue a token for your application to be used
  • Your issuer sends the user’s browser back to the application with a token that has the claims your application needs on it

In step three you may be wondering how the issuer knows that the user is from a remote realm. Why doesn’t it think that she is a local user and thus attempt to authenticate her directly first? Of course by doing so the user wouldn’t get in and they will be upset about it. Also, how does the issuer know that the user is from one particular realm versus another?

You will have more than one partner and so all of them will be differentiated out there. The home realm discovery is where the issuer has to determine if the user is from the local realm or one of the partners. If that user is local then they can be authenticated directly. If they are remote then the issuer has to be able to find out what the URL is to redirect her to so that they can be authenticated by the home realm issuer.

There are a couple of different ways in which this situation can be handled. The first one is for the user to help in some way. When the browser of the user is redirected to the ADFS, it will stop the protocol and display a web page to the user. Here they will be asked what company they are employed by. The credentials in place are only good for one company per user so they can’t give you false information here and continue to with any hopes of gaining access.

Once the user clicks the link for the company they are with, the protocol will continue the process. The issuer will know what to do from there. You can also set it up so that the user is only asked which company they work for one time. After that there can be a cookie in the browser that will always display that information without it being asked for in the future.

There is another way to handle this and it involves adding some type of hint to the query string in the link that the user clicks on in the first step. This query string is called whr with the hr being representative of home realm. It is a good idea for the IT department to ensure all of the links to remote applications include this information. That way the application is more user friendly. At the same time it will protect the privacy of the company as it doesn’t require revealing who all of the partners happen to be.

The issuer is going to find this hint and then map to the right URL for the home realm of the user. This means they won’t need to ask the user who their issuer is because the application is going to use the information it has available. A cookie will be in place to make sure users don’t have to take time to answer such questions.

The best way to get the users help for web applications is through the use of a web page. They are going to be interactive and the browser will conveniently be able to display a home realm discovery page when necessary. You may be wondering how to take care of this when it comes to web services and even your rich clients? Information cards can be a very useful tool for such circumstances.

Share