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 ...
36. Please complete and turn
in your Session Evaluation
Form so we can improve
future events.
Presenter:
Brian Culver
Session Name:
Extranets & Claims
Authentication
Hinweis der Redaktion
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