Back Matter

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Appendix A: Glossary

The following is a list of terms and their definitions as they are used in this book.

Access Token – In the context of OAuth 2.0 and OIDC, a security token used by an application to call an API.

Account – A construct within a software application or service that usually contains or is associated with identity information and optionally privileges and which is used to access features within the application or service.

Application – A software application that issues requests to a server.

Application Programming Interface (API) – A software service interface that allows a client program to request resources or actions from the software service.

Authorization Code – In the context of OAuth 2.0 and OIDC, an intermediary, opaque code returned to an application and which represents the application’s authorization by the user to call an API on the user’s behalf. It is used to obtain security token(s).

Authorization Server – A service which implements the OAuth 2.0 protocol and enables resource owners (users) to authorize applications to access content they own at resource servers and which issues security tokens enabling the authorized access.

B2B (Business to Business) – A business model where services are targeted to businesses that use the services in some way to deliver a service to their customers.

B2C (Business to Consumer) – A business model where services are targeted to consumers who typically act on their own behalf.

B2E (Business to Employee) – A business model where services are targeted to businesses where the users are the employees of the businesses and act on their employer’s behalf.

Confidential Client – In the context of OAuth 2.0 and OIDC, an application that runs on a protected server and can securely store confidential secrets with which to authenticate itself to an authorization server.

Directory Server – A repository for storing, managing, and organizing information about resources. Directory server products have often been optimized for storing information that is frequently read but infrequently modified and used to store information about entities such as users, access control privileges, application configurations, and network printers. Information in directory services has been used for authentication and authorization of users.

End User or User – A human subject using applications or services and who is authenticated and authorized when accessing protected resources.

HS256 – Hash-based message authentication code (HMAC) using SHA256 hash function. A symmetric cryptographic algorithm that can be used for creating and validating a digital signature. It is one option for signing a JSON Web Token, but requires both the issuer and validator of the token to know the same secret.

Identifier – A single identifying attribute that points to a unique individual user or entity, within a particular context.

Identity – A set of attributes, including one or more identifiers, associated with a specific user or entity, in a particular context.

Identity Proofing – The process of vetting a user’s identity and profile information.

Identity Provider (IdP) – (1) A general term for an entity providing an identity service designed to authenticate users and provide assertions about an authenticated user and the authentication event. (2) In the context of the SAML 2.0 cross-domain single sign-on profile specification, a server which issues SAML 2.0 assertions about an authenticated subject and authentication event.

Identity Repository – A collection of users stored in a computer storage system, such as a database or directory service.

ID Token – In the context of OIDC, a token used to convey claims about an authentication event and an authenticated entity to a relying party (application).

Internet of Things (IoT) Device – A network-attached device that has an IP address and is capable of transferring information over a network without human interaction. Usually refers to dedicated-purpose devices such as sensors or smart appliances as opposed to general computing devices such as computer servers.

Least Privilege – A security principle of granting the minimum privilege level required for a task or operating at the lowest possible privilege level for a task.

Mobile Application – An application that executes on a mobile device as a native application.

Multitenant Application – An application deployment shared by multiple independent customers whose data is segmented into their own area of the application’s data storage. The separation between different customers’ data is enforced by the application and its storage, rather than the network.

Native Application – An application installed and run natively on a computing device.

OpenID Provider – In the context of OIDC, an OAuth 2.0 authorization server that authenticates a user and returns claims about the user and authentication event to a relying party (application) in accordance with the OIDC specification. Applications can delegate user authentication to an OpenID Provider.

Public Client – In the context of OAuth 2.0 and OIDC, an application that executes primarily on the user’s client device or in the client browser and cannot securely store secrets with which to authenticate itself to an authorization server.

Refresh Token – In the context of OAuth 2.0 and OIDC, a token that can be used by an application to request a new access token when a prior access token has expired or become invalid. With OIDC, a refresh request can optionally return an ID Token as well.

Relying Party – An entity that delegates authentication to an Identity Provider or OpenID Provider or delegates authorization to an authorization server and, in either case, relies on the results, usually in the form of security tokens. With OAuth 2.0 an API is a relying party and with OIDC and SAML V2.0, an application is a relying party.

Resource Owner – In the context of OAuth 2.0, a user that authorizes access to protected resources hosted at a resource server.

Resource Server – In the context of OAuth 2.0 and OIDC, an entity that contains protected resources.

RS256 – RSA Signature with SHA256 hash algorithm. An asymmetric cryptographic algorithm that can be used for creating and validating a digital signature. It is one option for signing a JSON Web Token, and unlike HS256, does not require that the issuer and validator of the token know the same secret.

Security Domain – A security domain is a logical construct that defines the boundaries of one entity’s control or ownership.

Service Provider – (1) A general term for an entity providing a service, such as an application, to a user. (2) In the context of the SAML 2.0 cross-domain single sign-on profile specification, a client entity which requests SAML 2.0 assertions about an authenticated subject and authentication event.

Single-Page Application (SPA) – An application with logic that executes primarily in a browser, by dynamically altering the displayed web page, rather than making requests to a server to render new pages to respond to user actions. A SPA is assumed to be a public client, as defined by OAuth 2.0.

User – See the definition for end user.

Web Application or Traditional Web Application – An application with logic that executes primarily from a protected server, by rendering new pages from the server to respond to user actions. Traditional web applications are assumed to meet the definition of a confidential client, as defined by OAuth 2.0.

Appendix B: Resources for Further Learning

This appendix lists resources which may be helpful for further learning.

OAuth 2.0

OAuth 2.0 Authorization Framework:

https://tools.ietf.org/html/rfc6749

OAuth 2.0 Threat Model and Security Considerations:

https://tools.ietf.org/html/rfc6819

OAuth 2.0 for Browser-Based Apps (Draft as of this writing):

https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01

OAuth 2.0 for Native Apps:

https://tools.ietf.org/html/rfc8252

OAuth 2.0 Security Best Current Practice (Draft as of this writing):

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12

OAuth 2.0 Device Authorization Grant (Draft as of this writing):

https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15

OAuth 2.0 Authorization Framework: Bearer Token Usage:

https://tools.ietf.org/html/rfc6750

Proof Key for Code Exchange by OAuth Public Clients:

https://tools.ietf.org/html/rfc7636

OAuth 2.0 Token Introspection:

https://tools.ietf.org/html/rfc7662

OAuth 2.0 Token Revocation:

https://tools.ietf.org/html/rfc7009

OAuth 2.0 Web Message Response Mode (Draft as of this writing):

https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00

JWT

JSON Web Token (JWT):

https://tools.ietf.org/html/rfc7519

OIDC

OIDC Specifications:

https://openid.net/connect/

SAML

SAML specifications. See especially the core, bindings, and profile specifications:

https://wiki.oasis-open.org/security/FrontPage

Security Assertion Markup Language (SAML) V2.0 Technical Overview:

www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

SAML Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0:

http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

Multi-factor Authentication

The FIDO Alliance:

https://fidoalliance.org/fido2/

WebAuthn:

www.w3.org/TR/2019/REC-webauthn-1-20190304/

Background Information

An explanation of cookies, including security guidance:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Explanation of Cross-Origin Resource Sharing (CORS):

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Brief outline of different approaches to authorization and access control:

https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7316.pdf

OWASP Top 10 – Critical security risks for web applications and how to avoid them:

www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

OWASP SAML Cheat Sheet:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SAML_Security_Cheat_Sheet.md

Two sites on open redirects:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md

https://cwe.mitre.org/data/definitions/601.html

Checking for breached passwords – I’ve Just Launched “Pwned Passwords” V2:

www.troyhunt.com/ive-just-launched-pwned-passwords-version-2

Privacy

A map showing the location and strength of privacy legislation around the world:

www.dlapiperdataprotection.com/

This web site presents the articles of the GDPR in a convenient fashion:

https://gdpr-info.eu/

Appendix C: SAML V2.0 Authentication Request and Response

SAML V2.0 authentication request and response messages contain a lot of information. We’ve assumed that most developers are using an SDK or authentication broker rather than implementing SAML V2.0 directly in their applications, and therefore their primary need is to understand SAML V2.0 requests and responses for troubleshooting purposes. As explained in Chapter 16 , the best way to debug issues with SAML V2.0 is to capture an HTTP trace, extract the SAML V2.0 request and/or response, and examine it. In the following sections, we’ll explain which fields to examine and what to look for.

SAML V2.0 Authentication Request

When an application needs a user authenticated by a SAML V2.0 identity provider (IdP), the application redirects the user's browser to the identity provider with a SAML V2.0 authentication request message. An authentication request message can vary substantially as many elements are optional. A sample request without a signature might look like the following (text in bolded italics has been substituted for the actual values):

<samlp:AuthnRequest

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

Destination="IDP URL "

ID="ID "

IssueInstant="TIME ISSUED "

ProtocolBinding=

"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

Version="2.0"

ProviderName="SERVICE PROVIDER "

AssertionConsumerServiceURL="ACS URL ">

<saml:Issuer>SERVICE PROVIDER </saml:Issuer>

</samlp:AuthnRequest>

The request elements we have found most useful to check when troubleshooting SAML V2.0 are shown in Table C-1 , along with an explanation for each. A given request may have more or fewer elements, depending on a particular service provider’s configuration or implementation.

Table C-1

Useful SAML V2.0 Authentication Request Elements

Name	Purpose
AssertionConsumerServiceURL	URL at service provider to which the identity provider’s authentication response message should be sent. Often called the “ACS” URL.
AuthnRequest	Type of request. In this case, a request to authenticate a user.
Destination	URL for the recipient of the request, in this case, the IdP. This element was designed to prevent forwarding of messages to unintended recipients. This value must match the URL at which the request was received.
ForceAuthn	Can be used by requestor to indicate the IdP should prompt the user for credentials, regardless of the state of the user’s session at the IdP.
ID	The ID is a unique identifier for each request. When an IDP responds, the value of the InResponseTo element of the response should match the ID for the request that triggered the response.
Issue Instant	The time at which the request was issued. Identity providers should reject requests that are outside a certain time tolerance.
Issuer	Entity which generated the request, namely, the SAML V2.0 service provider. The IdP should check to make sure a request’s Issuer element matches a registered service provider.
NameIDPolicy	Can be used by the service provider to specify the type of identifier to use in identifying the authenticated user. Using an email address is common, but can conflict with privacy requirements.
ProtocolBinding	The requested mechanism by which the SAML response message should be sent over an underlying transport protocol. In practice, HTTP-POST is often used to avoid issues with browser URL size limits.
ProviderName	Human-readable name of entity issuing the SAML V2.0 request (the service provider).
RequestedAuthnContext	Can be used by requestor to specify requirements for the authentication context used by IdP when authenticating the user. Can be used to request a type or strength level of authentication, as agreed between service provider and IdP.
Signature	Signature information if request has been signed by issuer.
Subject	Used to specify the desired subject (user) for the requested authentication assertion.
Version	The version should be “2.0” for SAML V2.0.

A SAML V2.0 service provider (application) can send a SAML V2.0 request to an identity provider using a few different bindings. These indicate the mechanism for sending the message over underlying transport protocols. In practice, the HTTP-Redirect and HTTP-POST bindings are commonly used because they do not require direct network connectivity between the service provider and the identity provider. The HTTP-Redirect binding can be used with SAML V2.0 requests that are not digitally signed, but production environments are recommended to use signed requests to prevent request tampering. If a request is digitally signed, it typically needs to be sent using the HTTP-POST binding to avoid issues with browser URL size limits. The response or assertion from the identity provider must be digitally signed. Due to the size of a signed response, the HTTP-POST binding is typically used for responses.

SAML V2.0 Authentication Response

When an identity provider receives an authentication request, it will authenticate the user, if necessary, and return an authentication response to the service provider in the form of a SAML V2.0 response message which contains a SAML V2.0 assertion. In the case of an IdP-initiated flow, an IdP may send an unsolicited authentication response to a service provider. The SAML V2.0 response is an XML message with several components. The exact contents of the response can vary somewhat, depending on the nature of the request, the IdP configuration, and the information returned. Figure C-1 shows the high-level anatomy of a typical SAML V2.0 authentication response message to help you understand the structure of these often lengthy messages. (Note: A Signature element can be associated with an Assertion, the Response, or both. We have shown it in the Assertion for this sample.)

Figure C-1

Structure of a Sample SAML V2.0 Authentication Response

A sample SAML V2.0 authentication response is shown in the following sections. We’ve replaced specific values with explanatory text in bolded italics and provided a table after each snippet to indicate what’s useful to check when debugging.

Response

A SAML V2.0 authentication response message starts off with “samlp:Response” and includes the information shown in the snippet that follows and explained in Table C-2 .

<samlp:Response

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

ID="ID "

InResponseTo="ID OF CORRESPONDING REQUEST "

Version="2.0"

IssueInstant="TIME ISSUED "

Destination="ACS URL of Service Provider ">

<saml:Issuer

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ISSUER OF RESPONSE – IDENTITY PROVIDER

</saml:Issuer>

<samlp:Status>

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success "/>

</samlp:Status>

Table C-2

SAML V2.0 Authentication Response Elements Useful for Troubleshooting

Element	Description
InResponseTo	This response element should match the ID of the authentication request which triggered the response (for service provider–initiated cases).
IssueInstant	Time at which the response was issued. This can be checked for correct time to detect time skew issues. Service providers should reject responses that are older than a configured time tolerance.
Destination	The Assertion Consumer Service (ACS) URL where the service provider receives the response. Service providers should validate that the Destination URL in the response is where they received the response.
Issuer	The issuer of the response. Should match the expected identity provider.
Status	The Status element contains the result of the authentication request. Successful authentication is required for a status of “Success.”

Authentication Assertion (Beginning)

The beginning of the assertion element of a response contains an ID, the instant at which the assertion itself was issued, and the identity of the assertion issuer as shown in the following snippet and explained in Table C-3 .

<saml:Assertion

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

Version="2.0"

ID="ID FOR ASSERTION "

IssueInstant="TIME ASSERTION ISSUED ">

<saml:Issuer>ENTITY ISSUING ASSERTION </saml:Issuer>

Table C-3

SAML V2.0 Authentication Assertion Elements Useful for Troubleshooting

Element	Description
IssueInstant	Time at which the assertion was issued. This can be checked for correct time to detect time skew issues. Service providers should reject responses that are older than a configured time tolerance.
Issuer	The issuer of the response. Should match the expected identity provider.

Digital Signature for Authentication Assertion

The digital signature provides integrity assurance for the signed element. The IdP must sign either the assertion or the response when the HTTP-POST or HTTP-Redirect binding is used, and can sign both. The typical elements to check are shown in Table C-4 . Portions of this element are not shown for brevity.

<Signature

xmlns:="http://www.w3.org/2000/09/xmldsig#">

...

<SignatureMethod Algorithm=

"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 "/>

...

</SignedInfo>

<SignatureValue>DIGITAL SIGNATURE </SignatureValue>

<X509Certificate>CERTIFICATE </X509Certificate>

</X509Data>

</KeyInfo>

</Signature>

Table C-4

SAML V2.0 Assertion Signature Elements Useful for Troubleshooting

Element	Description
SignatureMethod	Check that the signature algorithm used by the IdP is an algorithm accepted by the service provider implementation.
Certificate	Check that the certificate shown is correct for the IdP and matches IdP metadata configured at service provider.

Subject

The Subject element identifies the authenticated user. A very common issue is that an identifier specified by the identity provider in the assertion is different from the identifier expected by a service provider (application) for the user.

<saml:Subject>

<saml:NameID

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">USER IDENTIFIER

</saml:NameID>

<saml:SubjectConfirmation

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData

NotOnOrAfter="EXPIRATION FOR SUBJECT DATA "

Recipient="SERVICE PROVIDER ACS URL >"

InResponseTo="ID FROM REQUEST "/>

</saml:SubjectConfirmation>

</saml:Subject>

Table C-5

SAML V2.0 Subject Elements Useful for Troubleshooting

Element	Description
NameID	Contains an identifier for the authenticated user.
NotOnOrAfter	Specified validity period for subject data. This time should not have already passed when the assertion is received.
Recipient	This element should match the ACS URL to which the response was delivered. Used by a service provider to ensure it is the intended recipient of an assertion it receives.
InResponseTo	This element should match the ID of the authentication request which triggered the response (for service provider–initiated cases).

Conditions

The Conditions element contains conditions on the use of the assertion which should be checked by a service provider.

<saml:Conditions

NotBefore="BEGIN VALIDITY TIME "

NotOnOrAfter="END VALIDITY TIME ">

<saml:AudienceRestriction>

<saml:Audience>INTENDED RECIPIENT </saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

Table C-6

SAML V2.0 Conditions Elements Useful for Troubleshooting

Element	Description
NotBefore	Start of validity period for assertion. This time should have passed when the assertion is received.
NotOnOrAfter	End of validity period for assertion. This time should not have already passed when the assertion is received.
Audience	Audience (intended recipient) of the assertion. May be specified in URN format. Used by a service provider to ensure it is the intended recipient of an assertion it receives.

Authentication Statement

The AuthnStatement element indicates when authentication occurred, and the AuthnContextClassRef can be used to return an indicator of the strength of authentication mechanism used. This section of the response is not typically a frequent cause of issues.

<saml:AuthnStatement

AuthnInstant="2019-01-19T19:11:28.407Z"

SessionIndex="SESSION INDEX ">

<saml:AuthnContext>

<saml:AuthnContextClassRef>

urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

Table C-7

SAML V2.0 AuthnStatement Elements Useful for Troubleshooting

Element	Description
AuthnContextClassRef	If a particular AuthnContextClassRef was requested, this can be checked to see if it matches the requested value.

Attribute Statements

Attribute statements are used to convey additional user profile attributes about the user. A frequent cause of issues is a mismatch between attributes expected by an application and the attributes delivered in a SAML assertion. The specific attributes will vary across different applications and identity providers. We have shown two attributes in the following snippet, one for a user identifier and one for a user’s email address. The list of attribute statements in an assertion should be checked to ensure all attributes required by an application are delivered in the assertion.

<saml:AttributeStatement

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<saml:Attribute

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier " NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml:AttributeValue xsi:type="xs:string">

USER IDENTIFIER

</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute

Name=

"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress "

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml:AttributeValue xsi:type="xs:string">

USER EMAIL ADDRESS

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

</samlp:Response>

Appendix D: Public Key Cryptography

This appendix provides a brief description of how public and private keys are used to encrypt and sign tokens in a public key cryptography scheme.

With public key cryptography, there is a private key and a public key. The private key is a long string of random characters. A public key is generated from the private key. The two keys are called a key pair. The owner of a key pair should keep the private key a secret, but the public key is designed to be distributed to others and used as described in the following.

To encrypt a message, the sender uses the public key of the intended recipient to encrypt the message. Once it is encrypted, only the recipient, who holds the matching private key, can decipher the message.

To digitally sign a message, the signer uses its private key to digitally sign the message. The recipient of the message uses the sender’s public key to verify the signature on the message.

Appendix E: Troubleshooting Tools

The following sections contain tools the authors have found useful for troubleshooting issues with applications using identity protocols.

Capture an HTTP Trace

An HTTP trace is essential for troubleshooting many scenarios. The following instructions indicate how to access trace features in different browsers, at the time of writing. A search for “How to capture an HTTP trace in <name of browser>” should provide current instructions if the following instructions no longer apply:

Chrome

Open Developer Tools.
Click Network tab.
Check the “Preserve Log” option, if not already checked.
After capturing a trace, you can right-click to save the trace in a .har file.

Firefox

There is a nice extension called Live HTTP Headers that is handy with Firefox.
Alternatively, you can open a new tab in Firefox and type “about:networking”.
The default settings are usually fine, but can be adjusted.
Click Start Logging, then do the actions which cause the issue.
Click Stop Logging, noting the location of where Firefox will save the file.

Internet Explorer

Press F12 to bring up Developer Tools.
Click the Network tab.
Reproduce the issue.
Click the Save button.

Safari

In Safari Preferences, Advanced, turn on “Show Develop Menu in Menu bar.”
When viewing a site, use the Develop ➤ Show Web Inspector to view.
Click the Network tab.
Turn on Preserve Log.
Use “Export” to save the HTTP trace to a .har file.

View a HAR File

If you can reproduce an authentication/authorization issue, you can view the HTTP trace of the issue in your own browser. However, if you need to view an HTTP Archive file captured by someone else, the following tools will be useful.

Caution

Remember that HTTP trace files may contain sensitive information such as passwords or security tokens.

If the tools listed as follows are no longer available, you should be able to find new ones by searching for “HTTP Archive View” or “How to view a .har file.”

Chrome

The Chrome browser supports the ability to import a .har file.

Open Chrome Developer Tools Network tab.
Drag and drop your .har file onto the tab.

Google .har file analyzer

Google provides a web site which can be used to view HTTP Archive (.har) files.

https://toolbox.googleapps.com/apps/har_analyzer/

Fiddler

Fiddler, another useful network trace tool, can also be used to view .har files.

https://docs.telerik.com/fiddler/KnowledgeBase/ImportExportFormats

Capture a Network Trace

To capture API traffic originating from a back-end application component or native application, you can rely on your favorite debugger or a network trace tool such as the following:

Fiddler

https://docs.telerik.com/fiddler

Charles Proxy

www.charlesproxy.com/

View Security Tokens

The ability to view security tokens issued by identity providers greatly aids the debugging process. Table E-1 contains some of our favorites.

Table E-1

Useful Tools for Viewing Security Tokens

Tool	Purpose
https://jwt.io	Tool provided by Auth0 for viewing JWT tokens
https://samltool.com	Tool provided by OneLogin for viewing SAML tokens
https://samltool.io	Tool provided by Auth0 for viewing SAML tokens

Test APIs

A tool for testing API calls, without the added complexity of a client application, can aid debugging. Table E-2 contains tools we’ve found helpful for testing calls to APIs.

Table E-2

API Debugging Tools

Tool	Purpose
https://getpostman.com	Tool for learning, debugging, and testing API calls
https://insomnia.rest/	Tool for learning, debugging, and testing API calls

Appendix F: Privacy Legislation

This section contains information on privacy-related legislation. Countries around the world are recognizing the need to enact legislation to protect personal information. It is beyond the scope of this book to provide a comprehensive list of privacy legislation as the list is long and new legislation is being introduced on an ongoing basis. In fact, at the time of writing, the privacy legislation in several countries is undergoing significant revision, in some cases to align more closely with the GDPR.

We will provide resources in the following for learning more about the primary privacy legislation applicable to the EU, namely, the GDPR, and legislation in the United States, which takes a sectoral approach to privacy legislation. We’ve also provided resources to help you find legislation applicable to other countries and to stay on top of privacy changes around the world.

The information provided in the following does not constitute legal guidance, and we recommend that organizations consult with legal and privacy professionals in the development of any privacy compliance efforts.

European Union

The European Union updated its 1996 Data Protection Directive with comprehensive privacy legislation known as the EU GDPR, General Data Protection Regulation. ⁱ The GDPR took effect in 2018 and applies to any entity that receives, stores, or processes data about persons in the EU and includes stiff fines for noncompliance.

Note that individual countries within the EU may enact additional country-specific legislation for implementation of the GDPR.

United States

In the United States, there are several privacy-related laws rather than one single federal privacy law. Privacy legislation in the United States uses a sectoral approach with different laws for different industry sectors and for some individual states:

GLBA (Gramm-Leach-Bliley Act) ⁱⁱ – Specifies privacy and security requirements for the financial industry governing the handling and protection of NPI (Non-Personal Information).
HIPAA (Health Insurance Portability and Accountability Act) ⁱⁱⁱ – Specifies privacy and security requirements for the healthcare industry, governing personal data as well as information about a person’s healthcare, health status, and payment for healthcare.
FTCA (Federal Trade Commission Act) ^iv – Protects consumers against deceptive or unfair business practices, which may include uses of personal data that do not conform to published privacy notices.
FCRA (Fair Credit Reporting Act) ^v and FACTA (Fair and Accurate Credit Transactions Act) ^vi – Governs protection of personal data, including a person’s credit score, capacity for credit, and any personal characteristics related to credit worthiness. It also obligates financial institutions to implement measures to detect and respond to suspected instances of identity theft, via the Identity Theft Red Flag Rule.
CAN-SPAM (Controlling the Assault of Non-Solicited Pornography and Marketing) ^vii – Governs the use of unsolicited commercial emails whose primary purpose is advertisement or promotion of commercial products or services.
TCPA (Telephone Consumer Protection Act) ^viii – Governs telemarketing calls and the use of automated calls, otherwise known as robocalls.
COPPA (Children’s Online Privacy Protection Act) ^ix – Governs the collection, use, and disclosure of information about children under the age of 13 for protection from unfair or deceptive practices. It places requirements on web sites or online services targeted to children under 13 or which knowingly have personal data about children under 13.
VPPA (Video Privacy Protection Act) ^x – Originally established in 1988 and amended in 2012, it governs the protection of personal data related to rental or sales of videos.

In addition, a patchwork of different privacy laws is being enacted in the absence of national legislation in the United States. Two examples are

California Consumer Privacy Act (CCPA) ^xi – California has enacted the California Consumer Privacy Act (CCPA) which takes effect in January 2020. The CCPA entitles California residents to know what personal data is being collected, whether it’s sold or shared, the right to opt out to the sale or sharing of their personal data, access to their data, and equal service and price even if they exercise their opt-out choice.
Vermont Data Broker Privacy Law ^xii – Vermont has enacted legislation that applies to data brokers that collect, store, aggregate, and sell data about data subjects. This applies to brokers who don’t have a direct relationship with the data subjects. The law requires data brokers to be transparent about their practices by registering with the state, secure the data they hold, and to not use personal data to harass or discriminate against data subjects. The Vermont law also requires free credit freezes to protect consumers whose identity has been stolen.

For information on other states, the International Association of Privacy Professionals has prepared a chart comparing US states’ passage of comprehensive privacy legislation. ^xiii

Other Countries

For information on privacy legislation in other countries, we have found the following sites useful for identifying privacy laws in each location and tracking news on privacy changes:

DLA Piper – Data Protection Laws of the World ^xiv
United Nations Conference on Trade and Development – Data Protection and Privacy Legislation ^xv
International Association of Privacy Professionals (IAPP) – (Some content for members only) ^xvi

In reviewing privacy legislation, it is worth noting that in some countries, there is different legislation for private sector businesses vs. public sector entities, and there may be additional legislation enacted by regional governments or for specific industries. For example, in Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) ^xvii applies to private sector businesses in Canada, whereas the Privacy Act ^xviii applies to federally regulated public bodies in Canada. In addition, some Canadian provinces have enacted additional privacy legislation.

Notes

Appendix G: Security Compliance Frameworks

Security frameworks provide a list of controls that represent requirements that would reasonably be expected of an organization to adequately secure systems and information under its control. We list here some security frameworks we have had occasion to review, in two sections. The first section contains general security frameworks that are not specific to an individual country or government. The second section presents several security requirements or frameworks that are specific to the United States.

General Security Frameworks

The following is a list of security frameworks, in alphabetical order.

Center for Internet Security – Top 20 Controls

The CIS Controls ⁱ are a series of 20 foundational cybersecurity controls intended to eliminate the most common attacks.

Cloud Security Alliance

The Cloud Security Alliance ⁱⁱ has a mission to promote best practices for security assurance for cloud providers. CSA has a three-level certification program called CSA STAR based on a published framework of security controls known as the Cloud Controls Matrix (CCM).

ISO 27000

ISO 27000 ^xiii is a family of standards published by the ISO (International Organization for Standardization) for information security management systems. Figure G-1 shows the ISO/IEC 27000 family of requirements, guidelines, and standards.

../images/475485_1_En_BookBackmatter_Fig2_HTML.png — Figure G-1
ISO/IEC 27000 ISMS Standards Family

Each of the standards/guidelines in the diagram may be purchased from ISO. A certified, independent auditor is required to verify compliance with the framework controls. After an audit of an organization’s evidence of compliance, a report is issued for the audit period stating if the controls were met. Organizations that pass the audit can place a certificate seal on their web site.

PCI DSS

The PCI DSS (Payment Card Industry Data Security Standard) ^iv was created by the payment card industry. Any vendor processing credit card data is expected to be compliant with the PCI DSS standard. It also applies to other systems that can impact the security of systems subject to PCI DSS.

US Frameworks

The following frameworks are applicable to the United States. They may be applicable to private sector organizations or applicable to government agencies and those doing business with them. Even if they are not mandatory for your project, a lot can be learned about best practices by studying the requirements, which may be useful in preparing for an audit or future requirements.

CJIS Security Policy ^v – Criminal Justice Information Services Security Policy

In the United States, the Criminal Justice Information Services (CJIS) Security Policy governs the protections which must be provided for the handling of personal data related to criminal justice, including fingerprints and criminal background records.

FFIEC Information Technology Examination Handbook and Cybersecurity Assessment Tool ^vi

The US Federal Financial Institutions Examination Council (FFIEC) unifies standards and principles and provides security guidance for financial institutions. The FFIEC has published the Information Technology Examination Handbook which consists of 11 booklets including one on Information Security. It has also published the Cybersecurity Assessment Tool which includes principles and standards in the Examination Handbook. The Cybersecurity Assessment Tool can be used as a self-assessment tool to prepare for an examination or audit.

FISMA – Federal Information Security Management Act ^vii

FISMA requires each US federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source. The FISMA standards include NIST publications FIPS-199, FIPS-200, and the NIST 800 series.

FedRAMP – Federal Risk and Authorization Management Program ^viii

FedRAMP defines a process for the evaluation, authorization, and monitoring of the security of cloud service providers used by US federal agencies. FedRAMP approval is required before a cloud service can be used by a federal agency (with a few very limited exceptions).

GLBA Safeguards Rule ^ix

This portion of GLBA (Gramm-Leach-Bliley Act) requires financial institutions to have measures in place to protect personal data, including names, addresses, social security numbers, bank account, and credit card information, as well as credit and income history.

HIPAA ^x

In the United States, the Health Insurance Portability and Accountability Act has a security component known as the HIPAA Security Rule. This rule establishes standards for the protection of electronic personal health information. This includes personal data related to healthcare, health status, and payment for healthcare.

HITECH Act ^xi

In the United States, the HITECH (Health Information Technology for Economic and Clinical Health) Act governs the adoption of technology for managing electronic health records. Subtitle D of this act covers the security and privacy of electronic health information.

NIST ^xii

The National Institute for Standards and Technology in the United States is a government body that publishes standards. The NIST cybersecurity framework is a voluntary framework of standards, guidelines, and best practices for cybersecurity. This framework references the NIST 800 series of publications which provide guidelines and technical specifications for cybersecurity.

SOC (Service Organization Control)

SOC1

A SOC1 report focuses on a service organization’s controls that are likely to be relevant to an audit of the entity’s financial statements. Control objectives are related to both business process and information technology. SOC1 reports follow the Statement on Standards for Attestation Engagements (SSAE) 18 standard.

SOC2

Service Organization Control 2 is a set of controls against which a company is audited, related to security, privacy, confidentiality, processing integrity, and/or availability. The specific set of controls for SOC2 is defined by each company. As the SOC2 assessment is not based on an open standard set of controls, information on the company-specific controls is included in the SOC2 report, prepared by an auditor, after a SOC2 compliance audit. The SOC2 report was created in part because of the rise of cloud computing and business outsourcing of functions to service organizations. These are called user entities in the SOC reports. Liability concerns have caused an increase in demand in assurance of confidentiality and privacy of information processed by companies and organizations.

Notes

Index

A, B

Access policy enforcement

Account requirements

account linking

delegation

impersonation

mergers and acquisitions

progressive profiling

API

add custom claims

authorization

back-end API

client application

extensibility

front end

SeeFront-end functions

front-end application

helper function

Introspection specification

JWT-formatted access

OAuth 2.0 scopes

OpenID Provider

processing request

test

user authorization

Authentication

biometric factors

deployment

identity provider request

knowledge-based authentication

multi-factor authentication

OIDC

private cryptographic key

SAML 2.0

session timeouts

static password

step-down

step-up

stronger forms

Authorization

client applications

attributes

delivery

enforcement

OAuth 2.0 request

policy enforcement

application access

data access

functional access

user authorization

delivery

enforcement

profile attributes

transactional attributes

uservs. client application

C

Center for Internet Security (CIS)

Centralized user repository

Cloud Controls Matrix (CCM)

Cloud Security Alliance (CSA)

Compliance

assessment and certification

competitive advantage

data protection

definition

efficiency

elective compliance frameworks

GDPR

industry

list of activities

privacy compliance

reduce penalties

security compliance

security/privacy standards

Criminal Justice Information Services (CJIS) Security Policy

D

Deprovisioning

account termination

certificate of deletion

data transfer

delete account

preserve account record

preserve identities

reprovision requirements

right to erasure

secure deletion

Document-writing app

code-sharing web sites

compliance requirements

features and services

frameworks

identity provider service

management requirements

access controls

anonymous document creation

API calls

provisioning options

sensitive data

session timeout

single sign-on

user logs out

users log in

web-based single-page application

platform

E

Environment requirements

Identity Provider Discovery

multitenant applications

shared workstations

Exceptions

accounts

authentication mechanism

data restore

decommission

orphaned account

takeover

compromised security information

credentials

personal data

secrets

identity provider

account recovery requests

breached passwords

brute force attack

system outage

administrative access

authentication

provisioning process

External identity service

characteristics

customer types

factors

government-issued online identity

industry consortium

organization-controlled identity

organizations

self-registered identity

social provider accounts

F

Failures

cleartext passwords

encrypt sensitive data

insiders threat

multi-factor authentication

pay attention to process

phishy emails

secure coding practices

security vulnerability

Target’s HVAC

Federal Financial Institutions Examination Council (FFIEC)

Federal Information Security Management Act (FISMA)

Federal Risk and Authorization Management Program (FedRAMP)

Front-end functions

API calls

helper functions

logout

OpenID Connect

sessions

token management

tokens

user authentication

G

General Data Protection Regulation (GDPR)

Gramm-Leach-Bliley Act (GLBA)

H

Health Insurance Portability and Accountability Act (HIPAA)

Health Information Technology for Economic and Clinical Health (HITECH)

HTTP Archive View (HAR file)

Chrome

Google

Fiddler

HTTP trace

Chrome

Firefox

Internet Explorer

Safari

I, J, K

Identifier

Identities

access policy enforcement

account management and recovery

authentication

authorization

autonomous vehicles

definition

deprovisioning

events in life of

evolution of

IoT devices

logout

multi-factor authentication

personal agents

provisioning

robots

sessions

SSO

step-up authentication

Identity and Access Management (IAM) System

Identity attributes

account recovery

advantages/disadvantages

credentials reset

enterprise provider

helpdesk reset

password guidance

SCIM protocol

social providers

user profile data

validation

Identity defederation

Identity management

centralized user repository

design questions

easier adoption

e-identity initiatives

federated identity and SAML 2.0

identity challenges

OAuth 2.0

OIDC

OpenID protocol

per-application identity silo

sample application

smaller devices

SSO servers

standard protocols

stronger authentication

WS-Fed

Identity provisioning

administrative account creation

automated account

cross-domain account

manual account

approaches

invite-only registration flow

leverage external identity service

migration

bulk migration

gradual migration approach

supporting legacy hashing algorithms

progressive profiling

self-registration

L

Logout

application

application session

authentication broker

in designing

identity provider session

multilevel authentication

multiple user sessions

OAuth 2.0

OIDC

back-Channel

front-channel

specification

redirects

relying party client application

SAML 2.0

session termination

SSO

triggers

user sessions

M

Multi-factor authentication

N

National Institute for Standards and Technology (NIST)

Network trace tool

No email address

O

OAuth 2.0

access token

API call

with authorization

authorization code grant

authorization request

+ PKCE

response

token endpoint

client credentials

client profiles

confidentialvs. public clients

implicit grant

authorization request

URL hash fragment

overview

refresh token

resource owner password credentials

authorization request

resource server

roles

tokens and authorization code

without authorization

OpenID Connect (OIDC) protocol

authentication

authorization code and tokens

authorization code flow

authentication request

authentication response

token requests

client types

endpoints

hybrid flow

authentication request

response_types

ID Tokens

implicit flow

authentication request

authentication response

parameters

roles

session management

UserInfo endpoint

OpenID protocol

P, Q, R

Payment Card Industry Data Security Standard (PCI DSS)

People requirements

family account

temporary accounts

Per-application identity silo

Privacy legislation

European Union

other countries

United States

Private key

Proof Key for Code Exchange (PKCE)

Provisioning phase

S

SAML 2.0

assertion

attribute statements

authentication broker

authentication request

authentication response

AuthnStatement

condition

configuration

digital signature

federated identity

identity federation

identity provider

IdP-initiated flow

overview

protocol binding

SAML assertion

SAML profile

service provider

SP-initiated flow

SSO

subject

trust relationship

working principles

Security Assertion Markup Language (SAML) 2.0 protocol

SeeSAML 2.0

Security challenges

diversifying motives

evolving targets

ongoing breaches

Security frameworks

CIS controls

CJIS Security Policy

CSA

FedRAMP

FFIEC

FISMA

HIPAA

HITECH

GLBA

ISO 27000

NIST

PCI DSS

SOC

US Frameworks

Service Organization Control (SOC)

Sessions

application session

authentication broker

continuous authentication

duration

identity provider

multiple sessions

relying parties

renewal

token renewal

Single sign-on (SSO)

authentication mechanisms

benefits

consumer-facing environments

definition

identity provider

multiple identity providers

servers

session attributes

session duration

trade-offs

working principles

Status transitions

Step-up authentication

System for Cross-domain Identity Management (SCIM) protocol

T, U

Targets

cars

homes and business

medical implants and monitoring

perimeter protections

robots

Troubleshooting

API calls

application issue

applications impact

authentication/authorization

capture HTTP traces

cross checking

environmental factors

HTTP status code

identity protocol

independent browser windows

intermittent problem

JWTs and SAML tokens

parameters in a request

problem replication

sequence of interaction

symptoms and issues

test environment

token contents

tools

trace of HTTP and API calls

users impacted

validation errors

view HTTP traces

V

View security tokens

W, X, Y, Z

Web Services Federation Language (WS-Fed)

WriteAPaper application

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Back Matter

Create new playlist

Sign In

Sign Up

Index

A, B

C

D

E

F

G

H

I, J, K

L

M

N

O

P, Q, R

S

T, U

V

W, X, Y, Z

Table of Contents for
Back Matter