␡
- Identity Management Security Patterns
- Best Practices and Pitfalls
- References
This chapter is from the book
Best Practices and Pitfalls
This chapter is from the book
This chapter is from the book
This chapter is from the book
Best Practices and Pitfalls
Best Practices
- Externalizing Identity Management and Policy Functions. It is important to de-couple the identity management and policy administration functions (i.e., policy administration point) from the application logic. Many applications build their own identity management and policy functions and then run without interacting with other systems. These identity management and policy functions provide similar or duplicate functions, and thus are difficult to integrate with other applications. It is beneficial to use a common policy system (for example, a standardized policy decision point) to standardize security control and ease audit control, for compliance _reasons.
- Logging and Audit. Filter and customize your logging mechanisms for any change in user credentials or creation of security tokens for audit control. For example, you can customize a logging handler (as in Java Logging API) or appender (as in log4j) to send details of user credential changes or creation of security tokens to a customized audit log. This can address local regulations and compliance requirements.
- High Availability. Single sign-on and security token processing are critical security functions that need to be available to service requesters and _service providers. Their application security designs should have high-availability design, either by deploying multi-master directory server topology (on which some identity server products run) or by clustering application containers. A failure to provide high availability for them may result in monetary loss and security vulnerabilities.
- SAML Single Sign-on Profile. Developers can use SAML single sign-on profile to implement single sign-on. It is standards-based and is supported by many security vendor products. Developers should avoid using proprietary methods to implement cross-domain single sign-on. Because cross-domain single sign-on requires loosely coupled integration with different security infrastructures, SAML and Liberty provide a good security framework.
- Security Threat Mitigation. [SAML11Security] defines some best practices of mitigating security threats for SAML messages. This includes the use of digital signatures, the combined use of secure transport layer (for example, HTTPS) and reliable messaging, and adding timestamp checking in the SAML server.
- Strong Password Policy. Always reinforce strong password policies if username/password tokens are used.
Pitfalls
- Using Reusable Passwords in Creating Security Tokens. Reusable passwords refer to Username Passwords that are constant and are used multiple times to gain access to a system resource. They are usually susceptible to dictionary attacks.
- Using Default Settings. Some applications provide default settings that turn on all application functions as a convenience, which may open up security loopholes for unauthorized access. For example, a security product may have a default policy rule that grants anonymous access to the system. This type of default setting should be disabled.
- Using Minimal Security Elements. When implementing SAML assertion statements according to the latest SAML specifications, developers may want to populate only the mandatory elements and leave all optional elements. Developers may assume that they should only use the minimal set of data elements, because they may not have a full understanding of how to use all of these optional elements. Some optional security elements such as IPAddress (IP address of the SAML responder) and DNSAddress (DNS address) are helpful information for identifying the message origin, troubleshooting, and tracking suspicious events. Without using these optional elements, the tracking of suspicious service requests or problem troubleshooting would be difficult.