Skip to main content

Security : Identity Management in SharePoint2010

Image
By

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
Single SignOn using ADFS

Labels:

Comments

Post a Comment

Popular posts from this blog

SharePoint RPC Protocols Examples Using OWSSVR.DLL

By
What is SharePoint RPC Protocols? Part 1 This reference includes information about the methods and usage of SharePoint Foundation Remote Procedure Call (RPC) protocol. This protocol can be used in Win32-based applications or in ASPX applications to make HTTP POST requests to the server. Methods in this protocol that do not modify the contents of the database can also be used in URL protocol to make HTTP GET requests. Definition taken from http://msdn.microsoft.com/en-us/library/ms448359.aspx You will find the OWSSVR.DLL in SharePoint 2010 Server Physical Path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI and MOSS C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI OWSSVR.DLL List of commands DialogView  Display ExportList GetProjSchema GetUsageBlob HitCounter RenderView To read more about the OWSSVR.DLL command Please read the URL Protocol from Microsoft Blog having a URL http://msdn.microsoft.com/en...
1 comment
Read more

SharePoint 2013 Search Database Part 1

By
SharePoint 2013 Search architecture drastically change, as earlier in FS4SP 2010 we have 2 search applications “FASTContentSSA” and “FASTQuerySSA” and 7 total database in use. Following are the List of DB (FS4SP) FASTContentSSA Search Service Application DB Search Service Application Crawl Store DB Search Service Application Property Store DB FASTQuerySSA Search Service Application DB Search Service Application Crawl Store DB Search Service Application Property Store DB FASTSearchAdminDatabase : Fast Search Admin Database  In SharePoint 2013 search has only 1 Search Service application and 4 database in use. No property store database need any more, now the properties are directly stored inside the index component and all the index directly indexed to the physical system where FS4SP data comes from database as well as from the File system now data directly stored and indexed/ retried from the Physical disk because of this performance increase and search experien...
Post a Comment
Read more

STS CryptographicException Error : Key set does not exist

By
Common mistakes Both SharePoint Site and SSO Site NOT running on the same application pool. Application pool identity user doesn’t have permission to access the certification.  Solution to this problem Set the same identity pool to  : 2. Be sure to grant rights to the certificate for the App Pool running the web service Start -> Run -> MMC File -> Add/Remove Snapin Add the Certificates Snap In Select Computer Account, then hit next Select Local Computer (the default), then click Finish On the left panel from Console Root, navigate to Certificates (Local Computer) -> Personal -> Certificates You're certificate will most likely be here. Right click on your certificate -> All Tasks -> Manage Private Keys Set you're private key settings here. Add app pool account Reset iis
Post a Comment
Read more