This section offers frequently asked questions and answers on ADFS.
Active Directory Federation Services (ADFS) is an identity access solution from Microsoft that provides web-based clients (internal or external) with one prompt access to one or more Internet-facing applications, when the user accounts exist in different organizations and the web applications are located in altogether a different organization. ADFS lowers the complexity of password management and guest account provisioning. It can also play a significant role for the organizations that use Software as a Service (SaaS) and Web applications.
All internal DOI Requesting Parties should first consider Microsoft Windows Authentication or Kerberos prior to requesting an ADFS RPT, as there are additional benefits for these platforms. Only if these are determined to be less then ideal, should an RPT request be submitted.
Please refer to the Compliance with NIST Standards and Guidelines. NIST develops and issues standards, guidelines, and other publications to assist federal agencies in implementing the Federal Information Security Management Act (FISMA) and in managing cost-effective programs to protect their information and information systems.
See FISMA Implementation Project Page on NIST.gov
Source: Compliance With NIST Standards and Guidelines
Please follow this link for detailed instructions:
Source:
ADFS integration with SAML 2.0
Please follow this link for detailed instructions:
Source:
Configure Active Directory Federation Services
Please follow this link for detailed instructions:
onelogin help center
Source:
onelogin help center
ADFS changes are managed and governed via the DOI Systems CAB.
This policy issued September 27, 2016 states that all DOI Bureaus and offices are required to use the Department's current approved cloud contracts when procuring cloud services or receive a waiver. View the policy memo.
A requesting party is required to hold an Active Directory account. Therefore, if an external vendor is requesting a Relying Party Trust (RPT) with the Department of the Interior, they are required to have a DOI Sponsor.
Integrated Windows Authentication (IWA) is a term associated with Microsoft products that refers to the SPNEGO, Kerberos, and NTLMSSP authentication protocols with respect to SSPI functionality introduced with Microsoft Windows 2000 and included with later Windows NT-based operating systems. The term is used more commonly for the automatically authenticated connections between Microsoft Internet Information Services, Internet Explorer, and other Active Directory aware applications.
Integrated Windows Authentication works with most modern web browsers, but does not work over some HTTP proxy servers. Therefore, it is best for use in intranets where all the clients are within a single domain. It may work with other web browsers if they have been configured to pass the user's logon credentials to the server that is requesting authentication. Where a proxy itself requires NTLM authentication, some applications like Java may not work because the protocol is not described in RFC-2069 for proxy authentication.
Source: Wikipedia Entry on Integrated Windows Authentication
You will be asked for the following types of information in the ADFS Risk Assessment Questionnaire.
Submitter contact information (name, phone number and Bureau/office submitting request on the behalf of), System Name, System Owner, Authorizing Official, Authority to Operate Date, Attributes that are required to be passed from AD, If the system/application is included in a separate system boundary within CSAM, Identification of any risks associated with allowing this ADFS connection, Attribute CNs, LDAP Display Names, An explanation for each Attribute CN/LDAP Display Name, Exposure of Personally Identifiable Information (PII) or DOI/[Bureau/Office] sensitive information, Risk mitigation activities which have been taken or are in place associated with sharing the information attributes, Identify any mitigation steps that have been taken to address the risks, Identify any remaining risk elements, Identify the risks and any mitigation steps that have been employed to lower the risk of occurrence, If a Privacy Impact Assessment (PIA) been conducted, if a PIA has been completed what's the system name and CSAM location UII for the PIA
Kerberos /ˈkərbərɒs/ is a computer network authentication protocol that works on the basis of 'tickets' to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades (hellhound). Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.
Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication. It uses UDP port 88 by default.
Kerberos is used as a preferred authentication method: In general, joining a client to a Windows domain means enabling Kerberos as default protocol for authentications from that client to services in the Windows domain and all domains with trust relationships to that domain. In contrast, when either client or server or both are not joined to a domain (or not part of the same trusted domain environment), Windows will instead use NTLM for authentication between client and server.
Intranet web applications can enforce Kerberos as an authentication method for domain joined clients by using APIs provided under SSPI.
Many UNIX and UNIX-like operating systems, including FreeBSD, Apple's Mac OS X, Red Hat Enterprise Linux, Oracle's Solaris, IBM's AIX and Z/OS, HP's HP-UX and OpenVMS and others, include software for Kerberos authentication of users or services. Embedded implementation of the Kerberos V authentication protocol for client agents and network services running on embedded platforms is also available from companies.
Source: Wikipedia Entry on Kerberos
Relying party trusts are trust objects typically created in:
A relying party trust object consists of a variety of identifiers, names, and rules that identify this partner or web-application to the local Federation Service.
Source: Microsoft - Technet: Understanding Key AD FS Concepts
Security Assertion Markup Language (SAML, pronounced sam-el[1]) is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
The single most important requirement that SAML addresses is web browser single sign-on (SSO). Single sign-on is common at the intranet level (using cookies, for example) but extending it beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies.
Source: Wikipedia Entry on SAML
A DOI memo dated December 1, 2015 titled "Mandatory Use of Security Assertion Markup Language (SAML) 2.0 Standard for Cloud-Based, Web Application Authentication Information Exchange" describes this requirement.
Claims are statements (for example, name, identity, key, group, privilege, or capability) made about users—and understood by both partners in an Active Directory Federation Service (AD FS) federation—that are used for authorization purposes in an application. For more detailed information regarding claims, see this article on understanding claims on Microsoft TechNet.
The SHA (Secure Hash Algorithm) is one of a number of cryptographic hash functions. A cryptographic hash is like a signature for a text or a data file. SHA-256 algorithm generates an almost-unique, fixed size 256-bit (32-byte) hash. Hash is a one way function – it cannot be decrypted back. This makes it suitable for password validation, challenge hash authentication, anti-tamper, digital signatures.
Source: Xorbin article on SHA-256 Hash Calculator
"Requesting party" refers to the customer organization appealing to the DOI for a relying party trust. Once the requesting party's application has been approved and a trust has been created, it becomes a "federated partner." A federated partner is trusted by the Federation Service to provide security tokens to its end users (that is, users in the account partner organization) so that they can access Web-based applications in the resource partner.
A federation partner that is trusted by the Federation Service to provide security tokens to its end users (that is, users in the account partner organization) so that they can access Web-based applications in the resource partner.
Active Directory Federation Services
Active Directory
A claim of a named quality or characteristic inherent in or ascribed to someone or something.
A statement from a verifier to a Relying Party (RP) that contains identity information about a subscriber. Assertions may also contain verified attributes.
A defined sequence of messages between a claimant and a verifier that demonstrates that the claimant has possession and control of one or more valid authenticators to establish his/her identity. Secure authentication protocols also demonstrate to the claimant that he or she is communicating with the intended verifier.
A defined sequence of messages between a claimant and a verifier that demonstrates that the claimant has possession and control of one or more valid authenticators to establish his/her identity. Secure authentication protocols also demonstrate to the claimant that he or she is communicating with the intended verifier.
A statement that a server makes (for example, name, identity, key, group, privilege, or capability) about a client.
A claim rule that you author using the claim rule language to express a series of complex logic conditions. You can build custom rules by typing the claim rule language syntax in the Send Claims Using a Custom Rule template.
Source:
AD FS 2.0 Terminology
The type of statement in the claim that is made. Example claim types include FirstName and Role. The claim type provides context for the claim value, and it is usually expressed as a Uniform Resource Identifier (URI).
The value of the statement in the claim that is made. For example, if the claim type is Role, a value might be Contributor.
You will select "yes," when asked if you have an ATO. If further information is required that is not available in the conditional ATO, the security team will reach out with additional requirements
Credential Service Provider
A user, whose account resides in an account partner organization, who can access federated applications that reside in a resource partner organization.
A process that allows for the conveyance of identity and authentication information across a set of networked systems. These systems are often run and controlled by disparate parties in different network and security domains.
Trusted business partner that is allowed securing sharing of identity information with DOI OCIO via ADFS
The party (DOI) that manages the subscriber's primary authentication credentials and issues assertions derived from those credentials. This is commonly the credential service provider (CSP) as discussed within this document suite.
The Screen for mapping LDAP Attributes to Outgoing Claims should like the following image:
In order to show the LDAP attribute you want mapped please type:
(LDAP Attribute) ------> (Outgoing Claim)
Ex: User-Principal-Name -------> Name ID
Given-Name ---------> Given Name
E-Mail-Addresses ------------> E-Mail Addresses
The party that receives and processes the assertion identifying the subscriber.
Client seeking a federated trust partnership with the DOI OCIO.
Metadata is defined as the data providing information about one or more aspects of the data; it is used to summarize basic information about data which can make tracking and working with specific data easier. Your application's metadata can be obtained from the vendor.
The RPid is located in the Metadata: It is how the application identifies itself to ADFS. It is often a the URL used to access the application.
The RPid can be provided by whomever configured the application to SAML (this is often, but not always the vendor).
Relying Party Trust
Federated Partner
The Technical POC is the person that will be most capable of answering technical questions regarding the application. This may be the person submitting the form, or it may be someone else that is aware of the application/service requirements and can provide details to the ADFS development team as needed to complete request.
An ATO (Authorization to Operate) refers to the permission for a product to be used in an existing system. The ATO includes the following approved documents: PIA, SORN, Privacy Plan, and SSP for A&A.
A new Relying Party Trust refers to a request that has never been deployed into a production environment with the Department of the Interior by the Requesting Party organization. An existing RPT refers to a current Relying Party Trust that requires some modification (for example additional claims, a change in authentication rules, etc.).
A DOI Sponsor is an internal DOI federal point of contact representing the Requesting Party. The DOI Sponsor should be filled in with the name of the individual who is either the application/system owner or the individual who is responsible for the application/system. This role is specifically used if an external requesting party needs access to the DOI ADFS environment, but does not have a DOI Active Directory account.
See Roles and Responsibilities for an ADFS Relying Party Trust Request.
A Federated Application Onboarding Template Test will be requested.
A Federated Application Onboarding Template Prod will be requested.
See NIST Digital Authentication Guideline.
Visit the DOI Cloud Customer Portal.
Yes. In the subject line of the email you received from the ADFS Support Team immediately after submitting your ADFS Intake form is a "submission request number" that is recognizable by ADFS followed by a numerical value representing your request. Ex: ADFS17
An ATO (Authorization to Operate) refers to permission for a product to be used in an existing system. The ATO includes the following approved documents: PIA, SORN, Privacy Plan, and SSP for A&A. This information can typically be obtained from the requesting party's bureau/office.
The bureau/office that you indicate should represent the bureau/office that this request is being submitted on behalf of.
Visit the DOI Foundation Cloud Hosting Services Reading Room.
The Test Environment is where all requirements are tested prior to going live to ensure that all requirements are met, there are no bugs in the code, etc. One all testing is complete the application can go live, by being placed in a Production Environment.
Information resources management activities of all agencies require that information security and privacy be fully integrated into the system development process. For more information please follow the links below:
All information that is required to fill out the ADFS Request form can be found in the ADFS User Manual.