Pitfalls

We avoided many of the common pitfalls by adopting the security patterns and following the best practices mentioned earlier in this book. We chose to use a methodology that allowed us to address security throughout the development life cycle. This prevented us from being constrained by the architecture or design at the end, as often happens in real-world applications that fail to identify security requirements and incorporate them from the beginning.

We also have come close to falling into the pit of vendor lock-in. Our decision was to use a standards-based external identity provider and adopt standards-based mechanisms to demonstrate interoperability. The major difference is that in this case there were no vendor-specific APIs that would lock us in to a particular identity provider vendor. We have therefore employed the best practice of buy versus build over the slight drawback of using a vendor-specific identity provider. Throughout the case study, we followed a patterns-driven design process that helped us with a highly reusable solution approach and avoided our generating a vast number of unneeded security requirements from our business requirements.