Security : Identity Management in SharePoint2010
Supported authentication methods
SharePoint Server 2010 supports authentication methods that were included in previous versions and also introduces token-based authentication that is based on Security Assertion Markup Language (SAML) as an option. The following table lists the supported authentication methods.
Windows :- NTLM, Kerberos, Anonymous, Basic, Digest
Forms-based authentication :-Lightweight Directory Access Protocol (LDAP) ,Microsoft SQL Server database or other database, Custom or third-party membership and role providers
SAML token-based authentication:-Active Directory Federation Services (AD FS) 2.0, Third-party identity provider, Lightweight Directory Access Protocol (LDAP)
Before 2010 Authentication SharePoint Security methods are.
SharePoint 2001
· Windows Server 2000/IIS 5.0
· ASP 3.0
· Windows Authentication (Active Directory)
SharePoint 2003
· Windows Server 2003/ IIS 6.0
· ASP.NET 1.1
· 2.0 w/ SP1
· Windows Authentication (Active Directory)
SharePoint 2007
· Windows Server 2003/2008
o IIS 6.0/7.0
· ASP.NET 2.0
· Windows Authentication (Active Directory)
· Forms-Based Authentication (FBA)
o Allows users to connect through a web form
o ASP.NET 2.0 Membership Provider/Role Manager
o Can authenticate users against “any” user store
o Web SSO (ADFS), LDAP, SQL…
o One authentication method per SharePoint Zone
SharePoint 2010
· Windows Server 2008/2008 R2
o IIS 7.0/7.5
· ASP.NET 3.5
· Windows Authentication (AD)
· Claims-Based Authentication
o Windows Identity Foundation SSO. (4.0 Framework)
o Multiple authentication methods per SharePoint Zone (Url)
o Standards-based (WS-Trust, SAML)
o Automatic, secure identity delegation
o Definition and Scenarios
o Extranet Network Typologies
o SPUser Class for Developers.
Claims-Based Authentication (CBA) Terminology
In a nutshell, by using WIF’s Claims Based Authentication and Federated Identity, we extract the authentication process out of the application itself and place the burden elsewhere. Amongst other things, this allows us to use other Identity Providers such as Windows Live, Google, Facebook, etc.
Conceptually, from an end-user’s perspective, this “single sign on” model would virtually eliminate the need for the user to have to register with and remember a different username and password for every site. They register once with a given identity provider, for example Google, then they could log into your application by signing into their Google account and granting your application permission to their Identity Information. So if you needed their address or phone number, you could simply pull it from their token.
· Identity: security principal used to configure the security policy
· Claim (Assertion): attribute of an identity (such as Login Name, First Name, Gender, Age, etc.)
· Issuer: trusted party that creates claims
· Security Token: serialized set of claims (assertions) about an authenticated user
· Issuing Authority: issues security tokens knowing claims desired by target application (AD, ASP.NET, LiveID, etc.)
· Security Token Service (STS): builds, signs and issues security tokens
· Relying Party: application that makes authorization decisions based on claims
The steps involved are as follows:
Browser makes request to your application
Your application provides the address to your STS provider (external Service Token Services)
Browser goes to STS address and authenticates using the Identity Provider (Google)
STS provides browser with a token
Browser goes back to your application and provides said token.
External Links
Comments
Post a Comment