SharePoint Saturday Houston: SharePoint 2010 Extranets & Claims Authentication
•
0 likes•835 views
The document discusses Brian Culver's contact information and thanks attendees for participating in the first ever SharePoint Saturday event in the greater Houston area. It then provides an overview of claim-based authentication in SharePoint and how it allows for mixed authentication models across web applications and zones with different authentication types like Windows, Forms Based Authentication, and SAML. The document concludes by reminding attendees to complete a session evaluation form.
Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
Similar to SharePoint Saturday Houston: SharePoint 2010 Extranets & Claims Authentication
Similar to SharePoint Saturday Houston: SharePoint 2010 Extranets & Claims Authentication (20)
More from Brian Culver
More from Brian Culver (20)
Recently uploaded
Recently uploaded (20)
SharePoint Saturday Houston: SharePoint 2010 Extranets & Claims Authentication
- 2. Twitter: @spbrianculver E-mail: brian.culver@expertpointsolutions.com Blog: spbrian.blogspot.com
- 3. Thank you for being a part of the first ever SharePoint Saturday for the greater Houston area!
- 17. Claim-based Authentication Trust 3 SharePoint Au th e nt ic 4 at Identity Provider io Se n Security Token Service cu R eq rity (IP-STS) ue to st ken 5 Service token request Claims Providers 6 Security token response SharePoint ASP.net Client 1 R Active Directory eque STS Trust Membership st Reso 2 A urce uthe ntica te Requ est/R SharePoint e d i re LiveID SAML ct Authorization Based 7 Request Resource with service token
- 18. Mixed Authentication Multi-Authentication SharePoint SharePoint Farm Farm Web Application Web Application Windows Windows Authentication Zone: Default Authentication Zone: Default Regular label-callout text FBA Authentication Extended Web Application Extended Web Application Zone: Extranet FBA Zone: Extranet SAML Based Authentication Authentication FBA Authentication Extended Web Application Extended Web Application Zone: Intranet ... Zone: Intranet Windows Authentication Extended Web Application Extended Web Application Zone: Internet ... Zone: Internet ... Extended Web Application Extended Web Application Zone: Custom ... Zone: Custom ...
- 19. s
- 21. s
- 36. Please complete and turn in your Session Evaluation Form so we can improve future events. Presenter: Brian Culver Session Name: Extranets & Claims Authentication
Editor's Notes
- So today we are going to define an extranet and cover …
- Common implementation scenarios for ExtranetsRemote EmployeesTraveling sales force, Employees working from home offices or customer sites, Geographically dispersed virtual teamsLine of Business Applications, Collaboration, publishingWe have to start thinking about identification and permissions Internal Identities such as ADPartnersJoint ventures, shared projects, short and long term scenariosIsolated data, shared resources, security and restrictionsExternal and Internal IdentitiesVendors & CustomersCustomer Collaboration, Announcements and Publishing PortalsTargeted and segmented contentExternal Identities
- Network topology access– Infrastructure and the number of access pointsIdentity Management How to manage accounts? Types of users?Identity provider they live in.SSO – Log in one timeInfo Disclosure makes sure it is secure but data is properly isolated and not leaked.Antivirus to ensure secure data and content.The rich client experience Office integration, edit in Word and avoid multiple auth promptsLets look at three common network topologies …
- This configuration uses a reverse proxy server on the border between the Internet and the corporate network to intercept and then forward requests to the appropriate Web server located in the intranet. Using a set of configurable rules, the proxy server verifies that the requested URLs are allowed based on the zone from which the request originated. The requested URLs are then translated into internal URLs. AdvantagesSimplest solution that requires the least amount of hardware and configuration. Very economical.Entire server farm is located within the corporate network.Single point of data:Data is located within the trusted network.Data maintenance occurs in one place. Single farm used for both internal and external requests ensures that all authorized users view the same content.Internal user requests are not passed through a proxy server.DisadvantagesResults in a single firewall that separates the corporate internal network from the Internet.Corporate network is vulnerable if external users are compromised.
- A back-to-back perimeter topology isolates the server farm in a separate perimeter networkThis topology has the following characteristics:All hardware and data reside in the perimeter network.The server farm roles and network infrastructure servers can be separated across multiple layers. Combining the network layers can reduce the complexity and costEach layer can be separated by additional routers or firewalls to ensure that only requests from specific layers are allowed.Requests from the internal network can be directed through the internal-facing ISA server or routed through the public interface of the perimeter network.AdvantagesContent is isolated to a single farm on the Perimeter (extranet) Network, simplifying sharing and maintenance of content across the intranet and the extranet.External user access is isolated to the perimeter network.If the extranet is compromised, damage is potentially limited to the affected layer or to the perimeter network.By using a separate Active Directory infrastructure, external user accounts can be created without affecting the internal corporate directory.DisadvantagesRequires additional network infrastructure and configuration.Databases can be compromised in the perimeterWe manage the additional identity management store
- This topology splits the farm between the perimeter and corporate networks. The computers running Microsoft SQL Server database software are hosted inside the corporate network. Web servers are located in the perimeter network. The application server computers can be hosted in either the perimeter network or the corporate network. AdvantagesComputers running SQL Server are not hosted inside the perimeter network.Farm components both within the corporate network and the perimeter network can share the same databases.Content can be isolated to a single farm inside the corporate network, which simplifies sharing and maintaining content across the corporate network and the perimeter network.With a separate Active Directory infrastructure, external user accounts can be created without affecting the internal corporate directory.DisadvantagesComplexity of the solution is greatly increased.Intruders who compromise perimeter network resources might gain access to farm content stored in the corporate network by using the server farm accounts.Inter-farm communication is typically split across two domains.
- Authentication returns the security principal in the HttpContext.UserIIS AuthenticatesFBA requires authentication providers to implement the Membership Provider interfaceWebSSO requires authentication providers to implement the Membership Provider interface including an HTTPModule for the WebSSO ProviderMembership Provider:GetUser( string )GetUserNamebyEmailFindUsersbyEmailFindUsersbyNameRole manager: RoleExists, GetRolesForUser, GetAllRolesWebSSOHTTPModule: AuthenticateRequest Uses user auth cookie to set HttpContext.User with security principalEndRequest Used to catch the 401 responses from WSS, turns them into 302 redirect for auth to the WebSSO logon server.
- Classic – Windows Native (NTLM, Kerberos). SharePoint consumes the NT token into an SPUser.Claims – Windows (NTLM, Kerberos), FBA (LDAP, ASP.Net/SQL), SAML (ADFS, WSTrust, WSFederation)Support existing Identity infrastructureActive DirectoryLDAP, SQLFederation GatewaysWebSSO and Identity Management systems“Normalized” the authentication tokens.Enable automatic, secure identity delegationSupport “no-credential” connections to External web servicesConsistent API to develop SharePoint solutionsClaims authentication for Microsoft SharePoint Server 2010 is built on Windows Identity Foundation. Windows Identity Foundation Framework is a set of .NET Framework classes that are used to implement claims-based identity.
- An identity is a security principal such as Tom, a windows security token … much like a claimExcept The claim doesn’t contain the windows security token ID, instead it contains one or more attributes that “claim” the identify of TomThe issuer is a system that issues claim on an identity that we trust. Facebook (Texas) vs. Live ID (Lousiana) – Tom lives in which state?The security token is created in SAML (Security Access Markup Language) which is extensible to support any claim. Windows Security Token is not extensible. Issuing Authority – knows about the claim desired by the target application. (AD, ASP.NET, LiveID, etc.) STS – sees windows security token and converts it to a SAML tokenRelying party – system that believes the claim
- Client is using a web browser. The client makes a web request (HTTP GET)SharePoint responds with a 401 Unathenticated and 302 Url to authenticateThe Authentication request is submitted to, and processed by, the local STS or another SAML compliant Identity provider, such as LiveID.The identity provider validates the identity and returns the security token (NT Token/SAML Token)Does SharePoint trust the token? The SharePoint (relying party) STS finds the policy for the requesting Web application in the policy store and creates a token for the requesting user using identity assertion values in the attribute store. Token augmentation, we add additional claims. A valid security token (new SharePoint SAML token) is returned to the user and then submitted to the Web application. The Web Browser requests the SharePoint resource with the Shareoint security token. SAML token is converted into an SPUser.Note there are two different tokens: One from Identity Provider, another from SharePoint.
- Client is using a web browser. The client makes a web request (HTTP GET)SharePoint responds with a 401 Unathenticated and 302 Url to authenticateThe Authentication request is submitted to, and processed by, the local STS or another SAML compliant Identity provider, such as LiveID.The identity provider validates the identity and returns the security token (NT Token/SAML Token)Does SharePoint trust the token? The SharePoint (relying party) STS finds the policy for the requesting Web application in the policy store and creates a token for the requesting user using identity assertion values in the attribute store. Token augmentation, we add additional claims. A valid security token (new SharePoint SAML token) is returned to the user and then submitted to the Web application. The Web Browser requests the SharePoint resource with the Shareoint security token. SAML token is converted into an SPUser.Note there are two different tokens: One from Identity Provider, another from SharePoint.
- Client is using a web browser. The client makes a web request (HTTP GET)SharePoint responds with a 401 Unathenticated and 302 Url to authenticateThe Authentication request is submitted to, and processed by, the local STS or another SAML compliant Identity provider, such as LiveID.The identity provider validates the identity and returns the security token (NT Token/SAML Token)Does SharePoint trust the token? The SharePoint (relying party) STS finds the policy for the requesting Web application in the policy store and creates a token for the requesting user using identity assertion values in the attribute store. Token augmentation, we add additional claims. A valid security token (new SharePoint SAML token) is returned to the user and then submitted to the Web application. The Web Browser requests the SharePoint resource with the Shareoint security token. SAML token is converted into an SPUser.Note there are two different tokens: One from Identity Provider, another from SharePoint.
- Client is using a web browser. The client makes a web request (HTTP GET)SharePoint responds with a 401 Unathenticated and 302 Url to authenticateThe Authentication request is submitted to, and processed by, the local STS or another SAML compliant Identity provider, such as LiveID.The identity provider validates the identity and returns the security token (NT Token/SAML Token)Does SharePoint trust the token? The SharePoint (relying party) STS finds the policy for the requesting Web application in the policy store and creates a token for the requesting user using identity assertion values in the attribute store. Token augmentation, we add additional claims. A valid security token (new SharePoint SAML token) is returned to the user and then submitted to the Web application. The Web Browser requests the SharePoint resource with the Shareoint security token. SAML token is converted into an SPUser.Note there are two different tokens: One from Identity Provider, another from SharePoint.
- Mixed Mode Authentication – (MOSS 2007) Single SharePoint Web Application, extended IIS Applications with different Urls and authentication.Multi-Authentication - Single SharePoint Web Application with more than one authentication provider.
- Different scheme for different protocolsProtecting access from different channelsAnonymous web sites