Session 3c The SF SaaS Framework


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • If project is source controlled – manually check out web.config (WIF not smart enough to do so)
  • Session 3c The SF SaaS Framework

    1. 1. SaaS Security UsingFederated Identity ManagementAzure AppFabric Access Control Service (ACS)Windows Identity Foundation (WIF)
    2. 2. What Were The Requirements?• Favor proven security frameworks and industry standards over custom security code• Single sign on (SSO) between tenants• Preferably not own or manage sensitive data• Avoid account management in the app such as lost password, etc.
    3. 3. Our Solution: Federated Identity Management• Leverage popular web identity providers such as Google, Yahoo.• Leverage Azure ACS as an aggregator of these providers• Leverage WIF for integration with ACS and claims management
    4. 4. Concept Diagram Federation ProviderIdentity Providers OpenID ACS SAML Relying Party (RP) IIS Google * WIF Claim Yahoo STS
    5. 5. DemoSetup Azure AppFabric Access Control Service (ACS)
    6. 6. Demo – Preview Portal
    7. 7. Demo – Portal
    8. 8. Demo – Create Namespace
    9. 9. Demo – Manage Access Control
    10. 10. Demo – Identity Provider
    11. 11. Demo – Relying Party Application Settings
    12. 12. Demo – RP – Authentication Settings
    13. 13. Demo – Edit Rule Group
    14. 14. Demo – Generate Rules To Create Claims
    15. 15. Demo – WS-Federation Metadata
    16. 16. DemoSetup Windows Identity Foundation (WIF)
    17. 17. Demo – Add STS Reference
    18. 18. Demo – Application URI
    19. 19. Demo – STS Location
    20. 20. Demo – Add Project Reference
    21. 21. ASP.NET Request Validation Error Message: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo..."). Workaround For Testing: Solution For Production:
    22. 22. Authentication Flow Diagram 1 3 Browser 6 4 2 5 MVC Website Access Control Identity Providers(IP) Service (ACS) Google Yahoo WIF STS1. Request login returns 302 redirect to ACS 4. Post credentials, returns token with 3022. Request IP selection form from ACS redirect to ACS3. Request login form from IP 5. Validate and transform token to SAML claims. 6. Post SAML to MVC website callback. WIF processes and sets cookie.
    23. 23. DemoClaims Authentication And Authorization
    24. 24. Demo - Claims
    25. 25. Disadvantages• Your user identities are tied to your ACS namespace - challenging if you ever wanted to migrate away from your ACS namespace• Additional cost – you pay for each token issued• Reliance on external service for authentication• WIF is not well integrated into the .NET framework (but that improves in 4.5) – WIF is also not very DI friendly
    26. 26. Summary• Low barrier to entry for using existing social identities in your app• ACS and WIF encapsulate the complexity• Users don’t need to remember another username and password• Developers get to save time implementing and maintaining account management features