SharePoint Federated Identity Process – Part 4 – The Benefits and Limitations of SharePoint Identity Federation

You will find that the federated identity has a very flexible structure to it. With that in mind, Adam Buenz’s Software House is able to add customers when they have a trust relationship in place by the issuer and they create claims mapping. This is all very simple behind the scenes action due to the process of such mapping being a very simple process. However, it is also important to realize here that the actual software component order application didn’t change at all. When you create a federation there is only some minor changes to that overall structure that need to be taken care of.

With the claims of ARB Security Solutions the ability to read the name of the business and the name of the employees is there. There won’t be any mix ups when it comes to finding out who accessed the application from Adam Buenz’s Software House and who accessed it from ARB Security Solutions. As a result there is less upkeep involved with federated identity. The accounts don’t need to be copied and maintained even though there are many security realms associated with them.

However, there are some limitations in place to be aware of. First, the way in which the claims mapping works has to be evaluated. Anyone that is with ARB Security Solutions is able to track software component orders due to the way in which the requests are set up with the type role and the value of software component order tracker in place. What you should do though is limit exactly who in the business will have access. That is what we will take a closer look at. 

It is vital that you are able to set up trust relationships. In this scenario the two entities are using ADFS 2.0 for the issuer of their security tokens. A public key certificate needs to be in place. This will be in a file that the administrators from ARB Security Solutions will send to Adam Buenz’s Software House. It is as easy as attaching it to an email and sending.

The administrators for ARB Security Solutions will configure ADFS so that they requests from the Adam Buenz’s Software House issuer will be accepted. All that needs to be done for this to occur is to select TBD menu in the ADFS. The Adam Buenz’s Software House administration will install the certificate on the ADFS host. This allows the federation to work with both issuers.

Share

SharePoint Federated Identity Process – Part 2 – Federated Identity Environment Requirements

In order for federated identity to happen, we have to first identify the goals. In this scenario it is for the federated identity to be in place for the application Adam Buenz’s Software House offers and that ARB Security Solutions needs access to. There is one secure domain that will accept an identity from either of these two domains. No one will need any additional credentials in order to be able to access it. The Adam Buenz’s Software House issuer trusts the claims that come from them but also those that come from ARB Security Solutions employees.

There are some requirements that have to be satisfied. First, Adam Buenz’s Software House has to control access of the software component order pages. Otherwise they wouldn’t be able to allow ARB Security Solutions employees access to them. The concept of home realm discovery is involved here as that allows Adam Buenz’s Software House to find out which issuer has the credentials to do so. ARB Security Solutions will also need to make a decision about what employees are going to be able to access that software component order system.

There are few things here that need to be assumed for this scenario too. First, we assume that ARB Security Solutions has an issuer using the WS-Federation. This is important because it defines how businesses are able to share identities without breaking the boundaries of security that may be in place within their own systems.

The software component order system in use will have roles in place so that access can be controlled. This is done by having a claim in place for the type of role someone needs. There is also a value in place and that needs to be an software component order tracker. There will need to be legal documentation in place too between these two businesses so that their needs and rights are well protected. Only then can the federation legally be formed.

Share

SharePoint Claims Based Authentication Architectures Explained Part 3 SharePoint As A Browser Based Application

WIF, short for Microsoft Windows Identity Foundation, is a set of .net frameworks that allow for the creation of claimed aware applications. It gives the user the logic that is needed in order to successfully complete any WS-Federation requests. This is the protocol that builds onto others to offer the trust and security. That is why you are allowed to request a security token when you are using an application that is browser based.

With such a scenario, it appears that the claims in WIF are similar to authentication. When a user is going to sign in, the WIF redirects them to the logon page. Once the user has been authenticated then they will be taken back to the application automatically. You may see a page called Login.aspx but that could be nothing more than an empty page. This is there for those users that need to use a smart card for authentication.

All issuers will be configured to use a method that is natural and that is secure for them to sign in. A simple username and password is usually good enough. However, there are ways for Windows to cover the needs of employers that want a more secure method to be in place. Here are some examples to make that process easily understood.

wa = wsingin 1.0 wa is for action and it will tell you if you are logging in with the wisignin1.0 or if you are logging off with wsingout1.0.

wtreatlm = http://sharepointsecurity.com/SecureCenter/ – wtreatlm is for target realm. There is a Uniform Resource Indicator that is able to identify this application. The URI is used to identify the application that the user has logged into. It also allows other tasks to be done that are associated with the claims for the application as well as replying to addresses.

Once the issuer has authenticated who the user is, it gathers those claims that are necessary for the application with the wtrealm identifying what the target application is. All of this is offered with the security token and there is a privacy key. The application can encrypt the tokens too and then the public key ahs to be used to authenticate them.

The issuer will be told which application they are using so that the claims issued will only be for that particular application to operate. The issuer will ask the browser to take them back to the application. This will send the token to that application for the claims to be processed. After this is done, the user will have access to that given application.

Some of this process may sound familiar to you. This is due to the fact that the forms authentication uses a very similar technique inside of the return URL parameter. This is done when the issuer returns to the HTML page of the browser. This creates the

with the encoded tokens inside of it.

The action of the form is going to submit the toke to the URL that is configured for that application. The user won’t see this form because the issuer has JavaScript in place to post it. Should those scripts be disabled though the user will have to click a button in order to be able to post the response to the server.

For the user there is a Windows authentication in place. The user will click on the link in the application and then the browser will be redirected in a matter of seconds right back to the application. The user will login at that point. Should the issuer require more information from the user such as a username and password or the use of a smartcard it will be done at that time. From the users point of view this type of logon process is always the same no matter what they are accessing and that is what they are after.

Share