ADFS: ACTIVE DIRECTORY FEDERATION SERVICES
|
5
|
So I've been told that our PHP
application may need to support authentication using ADFS.
I've tried reading some of the
Technet docs, but it's full of Microsoft-speak that isn't hugely helpful.
Wikipedia is better (see below),
but perhaps some of the ServerFault community can fill in some of the gaps.
Active Directory Federation
Services (ADFS) is a software component developed
by Microsoft that can be installed on Windows Server operating systems to
provide users with single sign-on access to systems and applications located
across organizational boundaries. It uses a claims-based access control
authorization model to maintain application security and implement federated
identity.
Claims-based authentication is the
process of authenticating a user based on a set of claims about its identity
contained in a trusted token.
In ADFS, identity federation is
established between two organizations by establishing trust between two
security realms. A federation server on one side (the Accounts side)
authenticates the user through the standard means in Active Directory Domain
Services and then issues a token containing a series of claims about the
user, including its identity. On the other side, the Resources side, another
federation server validates the token and issues another token for the local
servers to accept the claimed identity. This allows a system to provide
controlled access to its resources or services to a user that belongs to
another security realm without requiring the user to authenticate directly to
the system and without the two systems sharing a database of user identities
or passwords.
In practice this approach is
typically perceived by the user as follows:
1.
The user
logs into their local PC (as they typically would when commencing work in the
morning)
2.
The user
needs to obtain information on a partner company's extranet website - for
example to obtain pricing or product details
4.
The
partner website now does not require any password to be typed in - instead,
the user credentials are passed to the partner extranet site using AD FS
5.
The user
is now logged into the partner website and can interact with the website
'logged in'
|
For a non-Microsoft person, what is
ADFS?
ADFS is Microsoft's solution for
Single Sign On and web based authentication.
It is used primarily to provide a
single set of credentials that can access a variety of sites not necessarily
hosted within the same domain.
How does it differ to things like
LDAP?
LDAP:
- Communicates using TCP/UDP on port 389 (or port 636 for LDAPS)
- Contains commands for searching/retrieving/adding/deleting/modifying users, profiles and other directory entries
- Can not be performed directly by a web browser, however HTTP authentication can be translated to LDAP using things like Apache's mod_authnz_ldap.
- When used for third-party website authentication, requires that username & password are provided to the third-party, which is not ideal for security.
- Is more of an open standard and has numerous Linux implementations.
ADFS:
- Better designed for the web as it communicates over standard HTTPS
- Follows a safer process similar (but not exact) to OAuth where the original username/password are provided directly to the organisation's ADFS server (or a proxy, but not the third-party), which if valid, returns a unique token that can be used to access a third-party website.
- Although it does use make use of some open standards (HTTPS, SAML etc.) it is Microsoft-specific and requires Internet Information Services (IIS) which only runs on Windows Servers.
How does it work? What kind of
information would be included in a typical request to an ADFS server? Is it
designed for both authentication and authorization?
It works by having a single site
(site A) that hosts the ADFS / ADFS proxy servers, which has access to the
credentials (usually by communicating with an Active Directory Domain
Controller). It is then given a trust between other sites (sites B & C)
that require authenticating through the ADFS.
When a user attempts to access site
B in their browser, the site redirects the user to the ADFS-proxy website (site
A) which asks for their username & password, authenticates them, returns a
set of cookies for remembering them, and redirects them back to the site B,
along with an access token.
If the user then attempts to visit
site C, they will also get redirected to site A for authentication from the
ADFS-proxy website. If the right cookies exist, the user will not be required
to enter their password again, but get instantly redirected back to site C with
a token.
The ADFS can be configured with
specific claims (or permissions) for the user, for authorization purposes. So
it can serve both roles. (Note the difference between authentication and
authorization.)
Some people prefer not to use it for
authorization but instead keep the permissions management in the third-party
website. The obvious downside is that both site A & B need to keep track of
user accounts, while in the scenario where ADFS handles both, only the ADFS
needs to be aware of the users.
Are ADFS servers typically accessible
from the internet (whereas corporate AD domain controllers would not be)?
Yes, nearly always. ADFS is based on
the notion that it will be primarily used for website authentication. And is
built around IIS.
The ADFS-proxy site is the one that
is usually accessible from the internet. However the ADFS itself is not. The
ADFS is generally a separate server from the ADFS-proxy.
- ADFS Server
Server that links to the credentials, and has the claims configuration as well as the trusts. Generally not publicly accessible. - ADFS Proxy Server
Server that hosts the IIS instance that has the login pages for the websites requiring authentication. Communicates back to the ADFS when requiring authentication. Generally publicly accessible.
Key Challenges that ADFS addresses
Prior to ADFS, many organizations
used to deploy separate Active Directory for authentication and authorization
for third parties in order to use their services. In majority of the cases, you
could result in becoming an account administrator for external users that may
expand rapidly when they need their password reset, have a new account added
and so on.
The other challenge is around
de-provisioning of users. You have no control over the users that leave your
partners, but their accounts remain active in your AD. This may result in
security incidents if an employee still has access.
Should I use ADFS?
- If you want have the requirement to allow users from another business (Contractor/Partner) to access your internal resources (web applications, messaging services & so on). The practical example suitable to many organizations is outsourcing, where your partners/contractors access your resources for supporting your business functions.
- If you are planning to move some parts of your IT to private or public cloud and want all the security factors to be seamless for the users. For example: In the case of a hybrid environment, some internal users are moved to Office 365.
Key Benefits
- Single Sign On (SSO)
- Minimizes password phishing
- Helps to minimize the need for repetitive logon exchanges
- Reduces the repetition and submission of user
credentials that can lead to higher helpdesk support cost and end user
exhaustion
- Industry Standard Identity protocols supported - Compatible with various security products/solutions that support the WS -* Web Services Architecture
- Eliminates the management of user accounts in a partner organization
- Extensible architecture - Provides an extensible architecture. For instance: Addition/modification of claims using custom business logic during claims processing.
Conclusion
ADFS is a very flexible technology
by Microsoft that provides authentication and authorization to applications
running in your environment to the extranet users of different organizations.
If you are planning to extend Active Directory outside of your environment or
transition to Office 365 or cloud, and want to reduce user account
administration effort while providing claims-aware federation, ADFS is the
perfect solution you can rely upon.
DFSR
Available in Windows Server 2008 R2 and later, it acts as a replacement for the DFS Namespaces
replication engine, Microsoft says. It is also a replacement for replicating
the SYSVOL folder in Active Directory Domain Services for domains using the
functional level of Windows Server 2008.
DFSR works by using an algorithm
called remote differential compression, which can detect changes to a file's
data and enable DFSR to replicate only these changed files.
Organizations must create groups for
replication and include folders that have been replicated to use DFSR.
Organizations can also manage DFSR by three different means: DFS Management,
any scripts that call for WMI
and the DfsrAdmin and Dfsrdiag PowerShell cmdlets.
Comments
Post a Comment