Single Sign-On is generally perceived as a shining beacon of architecture excellence in most of the corporations having an array of IT based services to facilitate a variety of business functions and operations. Windows Identity Foundation / Active Directory Federation Services is one of the mechanisms to facilitate single sign-on i.e. an integrated security across domains using a single authentication credential.
SSRS and Sharepoint are generally used together either in native or sharepoint integrated mode, to make reports available on a collaborative platform. When a claims based authentication mechanism like ADFS is used, users would try to access reports hosted on sharepoint and claims token (which also gets passed in the form of cookies with a particular configuration with ADFS) would get passed from domain to domain through the federation site. The biggest issue is with one of the limitation of this topology / design is to make the token reach SSRS so that it can identify the user. I have been evident of exactly such scenario, and the resolution adopted was to use Windows Integrated Security for the site in question and abandoning ADFS for the same.
As a technical architect, generally you would not find yourself in the limited periphery of technologies like MS BI and Sharepoint only. You would need a good understanding of technologies that touch your solution from any corner, as "Security" is one of the verticals in your architecture design and diagram. Remember that if you are a technical architect, you cannot wash off your hands with the theory that, "I am an architect, and I have no relation with technology !!!". This is true to the extent that this statement is made during solution design, but immediately after the solution design, one might be required to implement the solution and find the right technology stack to implement the solution. If you continue to make this statement even at this phase, the answer you can expect to receive from your program management is "W. T. F...." :)
SSRS and Sharepoint are generally used together either in native or sharepoint integrated mode, to make reports available on a collaborative platform. When a claims based authentication mechanism like ADFS is used, users would try to access reports hosted on sharepoint and claims token (which also gets passed in the form of cookies with a particular configuration with ADFS) would get passed from domain to domain through the federation site. The biggest issue is with one of the limitation of this topology / design is to make the token reach SSRS so that it can identify the user. I have been evident of exactly such scenario, and the resolution adopted was to use Windows Integrated Security for the site in question and abandoning ADFS for the same.
As a technical architect, generally you would not find yourself in the limited periphery of technologies like MS BI and Sharepoint only. You would need a good understanding of technologies that touch your solution from any corner, as "Security" is one of the verticals in your architecture design and diagram. Remember that if you are a technical architect, you cannot wash off your hands with the theory that, "I am an architect, and I have no relation with technology !!!". This is true to the extent that this statement is made during solution design, but immediately after the solution design, one might be required to implement the solution and find the right technology stack to implement the solution. If you continue to make this statement even at this phase, the answer you can expect to receive from your program management is "W. T. F...." :)
Here are some resources that can help to understand this limitation and ADFS in a better way.
1) SharePoint Adventures : Why isn't Claims working with SSRS?
2) SharePoint Adventures : How to identify if you are using Claims Authentication
3) Identity Developer Training Kit - Use this kit to download technical documentation related to Identity Framework
4) Creating VM Lab environment to test ADFS 2.0 and Step by Step Guides to setup ADFS 2.0
5) ADFS 2.0 Home page
Article 
No comments:
Post a Comment