Introduction to Design Architecture

We need to consider interdependencies, latency for the provisioning of accounts, for single sign on responses. If we link different directory services together, the default replication period is 15 minutes, for Microsoft’s Active directories.

Fifteen minutes: is that quickly, is that quick enough? Is that too slow? Do the changes replicate in between log ons? Lots of systems do not apply changes to accounts, to identities, until the account is logged on again. What data repositories do we have within our sites, between our sites, local, and in the cloud? And if we’re replicating data information, how long does this take? What interdependencies exist? We’ve given an example already when we looked at cloud-based identity providers with Ping Identity or Microsoft Azure. There are different paradigms of access, and there are different approaches and different resilience requirements that arise from the choice of the technology. We also have authentication, authorization, and accounting systems.

We need to select an appropriate identity source. Are we using radius or diameter to process some of these requests? Are we replicating information? Ultimately, we need to make sure that everything we’re doing has a good strategic fit. From a business perspective, from a functional perspective, and from a technical perspective, the single best way to do this is through involving and communicating with our stakeholders, our business stakeholders, our technical stakeholders, and our senior managers. So we need to ensure the congruence and alignment of the existing technical stack, the proposed acquisitions and developments, any partner services we may be using, any cloud services we may be using, the data integration, and also the availability and the security of any APIs.

The retention of personally identifiable information carries limitations under GDPR and equivalent privacy legislation. We need to understand any implications arising from our identity and access management system, again, at design stage so we can appropriately address any concerns. We’ve said personally identifiable information can be as little as an email address or a telephone number. We may need to provide right of access to citizens, to customers. And it may confer on us limitations on how we use that data, on how we store that data, on how we process the data. So international standards we’ve covered broadly. But just touching on it again, these vary. In Canada, we have PIPEDA. US, we have the Patriot Act.

We have regulatory compliance requirements such as PCI/DSS. And so all of these can heavily influence our identity and access management system. We revisit retention and compliance specifically during implementation just to remind ourselves that this heavily influenced what we must do, what we may be permitted to do as an organization.

So restrictions around encryption: we need to make sure that any implementation is export-compliant in terms of its controls or is compliant in terms of your local requirements. And if you’re a company operating online services, these are probably international, at which point the export compliance piece becomes really important. What is legal as an internet service differs from country to country. So in the country of hosting, typically is the consideration something may be legal. Your customer may be in a country where that is not legal at the point of consumption. So the point of service and the point of consumption may be different, especially when we are an international online company. There are some goods that are classed as dual use goods.

Things like the Playstation console was classed as a dual use good. It was technically classed as a supercomputer that could be used for military purposes. And here, restrictions can apply, and some of these can weaken our approach to identity and access management. So some of the requirements here can be less than 56 bit for AES encryption, which is a very, very weak level. It’s not a level we would choose to encrypt at. A 512-bit for RSA, RSA key sizes are longer than AES because RSA is an asymmetric encryption standard. And so the keys are much, much longer for an equivalent level of assurance, an equivalent level of strength.

Any security issues that arise for SAML, for TLS, in Australia, there is a piece of legislation that had been agreed whereby the state has required access to any encrypted data stored by individuals. And the level of requirement for this is very low. Individual law enforcement agencies can request this. So we have a potential here for something that is legal in our own country when we designed this offer, to be contravening local laws. We need to be very, very aware of where our services may be used and consequently how we must design the solution.

All of this lends us guidance to our design architecture, to our physical elements of the design architecture, and the on-premise, hosted, and cloud microservices architecture that we are potentially going to use. When we’re looking at design, if we are using hosted services, things like infrastructure as a service or platform as a service, we can request intelligent hand services. We can request remote physical capabilities, somebody to help change our backup tapes, somebody to press the reset button for us, if we’re using remote hosting.