Single Sign-On

The identity of a principal is stored in the Identity Provider (IdP), trusted by service providers (SP) which conversely rely on the identity information from the IdP as they may not manage or maintain a directory of identities.

IdP-initiated SSO refers to the scenario that the subject is authenticated by the IdP first, then gets access to the resources on the service providers.

SP-initiated SSO refers to the scenario that an unauthenticated principal requests the resources on the service providers and is redirected to the IdP for authentication.

A subject authenticated by the IdP can roam among the SPs.

Federated Identity

The system entities engaged in a federation manage their own directory. The identity information is mapped (not synchronized or replicated) across the directories in the federation.

A subject authenticated by any of the system entities can roam in the federation.

Identity as a Service (IDaaS) is an authentication infrastructure that is built, hosted and managed by a third-party service provider. IDaaS can be thought of as single sign-on (SSO) for the cloud.

An IDaaS for the enterprise is typically purchased as a subscription-based managed service. A cloud service provider may also host applications for a fee and provide subscribers with role-based access to specific applications or even entire virtualized desktops through a secure portal.

Source: https://searchmobilecomputing.techtarget.com/definition/identity-as-a-Service-IDaaS

• AWS: https://aws.amazon.com/blogs/security/introducing-aws-single-sign-on/
• Azure: https://blogs.technet.microsoft.com/cbernier/2014/09/02/identity-as-a-service-idaas/

Digital Envelope

The enveloped-data content type consists of an encrypted content of any type and encrypted content-encryption keys for one or more recipients.

The combination of the encrypted content and one encrypted content-encryption key for a recipient is a “digital envelope” for that recipient.

Content

The content is encrypted with the content-encryption key.

The data to be protected is padded, then the padded data is encrypted using the
content-encryption key.

Content-encryption Key

The content-encryption key for the desired content-encryption algorithm is randomly generated.

Any type of content can be enveloped for an arbitrary number of recipients using any of the three key management techniques for each recipient.

Source: RFC 3369: Cryptographic Message Syntax (CMS)

S/MIME and PGP

Both S/MIME and PGP support protecting the encryption/session key using the public-key encryption. At the conceptual level, S/MIME and PGP apply. The diagram is an excerpt from Wikipedia and I think that’s why PGP is the answer.

The session key in S/MIME can be exchanged through:

1. Key transport by public-key encryption (supported by CA)
2. Key agreement
3. Shared Key

References

• RFC 3369: Cryptographic Message Syntax (CMS)
• MIME
• S/MIME
• RFC 4134: Examples of S/MIME Messages
• COEN 350 S/MIME
• Chapter 41. Body Encryption and Signing via SMIME
• PKCS
• Understanding S/MIME
• Pretty Good Privacy
• Web of trust

This question of security culture is discussed in Luke’s group.

IMO, culture is a big issue and varies from company to company. I would

1. clarify the management’s expectation upon security and culture,
2. set the goals according to those expectations and/or requirements,
3. analyze the dimensions of security culture, and
4. define metrics and KPIs to measure if the goals are achieved.

The following are some factors to consider:

• the risk appetite of the board,
• arrangement of the security function,
• the soundness of the policy framework,
• security budget,
• meeting frequency or attendance of the management,
• the readiness of the management system,
• total hours of training and education,
• the number of incidents reported, and
• sense of urgency and accountability, etc.

Source: https://www.isc2.org/About/Member-Counts