Adding Images in Azure DevOps Wiki

The wiki pages get created in their own Git repository and the image files are also added there. You can browse the repos from within DevOps at; https://dev.azure.com/MyOrganisation/MyProject/_git/MyProject.wiki

The markdown path for the image should begin /.attachments/ and make sure if you are adding dimension you use =500x and not =500 if you exclude the height e.g.

![MyImage.png](/.attachments/MyImage-98765432-abcd-1234-abcd-a1234567890b.png =500x)

For more info, click here.

Cognitive complexity theory with example

The cognitive complexity definition is how capable people perceive things in their world. It also describes the number of cognitive processes required to complete a task. Things that are complicated to perform have more processes involved than simple tasks.

Making a sandwich, for example, is a simpler task than writing a term paper. Many more cognitive processes are involved in writing the paper, such as using online resources, doing effective research, and writing within a specific style and tone. Cognitive complexity can also help individuals analyze situations more accurately by allowing them to see shades of nuance and meaning more clearly. The core determining factor in the complexity of an individual’s cognition is their life experience and education. Exposure to complex situations, either through life experience or education and training, allows individuals to form mental constructs.

Expounding upon this theory of what is cognitive complexity is the personal construct theory, which states that individuals interpret the world through mental constructs. These constructs serve as shortcuts, aiding individuals in quickly analyzing situations and tasks. For example, someone could color-code their notebooks to make it easy to identify which notebooks are for which subjects, rather than sifting through multiples of the same color notebook. Mental constructs make it easier to solve complex problems by breaking down parts of the problem-solving process into automatic processes.

Cognitive complexity is also used in computer programming to help software engineers describe units of code. Cognitive complexity, in this sense, is how difficult it is to understand a unit of code in a program. Some functions and classes are straightforward and are easy to understand, while there are those with multiple parts with several logic breaks and references to other files that make it difficult to follow. Complex code is generally more prone to bugs because there are more areas for things to go wrong when the program is being executed. It also makes it more challenging to write new code that interacts with the old complex code, making rework necessary to simplify the code.

Cognitive Complexity Example

Imagine that there is an individual who is learning how to cook and opens their new cookbook to a recipe they’ve been considering. The recipe calls for several ingredients that they’ve never heard of before. So, they must take the time out to research these ingredients, figure out what they are, and search for them at the store. They also discover that they do not have a pan big enough to cook the meal, so they must also purchase a new pan capable of doing so. Meanwhile, an accomplished chef is making the same recipe. However, because they have more experience, they already know what the recipe calls for and have the ingredients in stock. They also already have the correct pan. The first individual consults the recipe for every step, lengthening the prep and cooking process. The chef knows the recipe by heart, so they get the meal prepped and cooked more quickly. In this cognitive complexity example, the chef has more mental constructs available to them from experience with the dish, resulting in less time spent prepping and cooking. They also know what ingredients do what, so if the flavor is off, they know what to add while the inexperienced individual might not.

Cognitive Complexity Communication

Cognitive complexity in communication refers to the number of psychological constructs an individual might use to describe someone. These psychological constructs generally refer to personality traits, like “energetic” or “caring.” Those who are more perceptive of others tend to use more psychological constructs to describe people. These people have higher interpersonal cognitive complexity, allowing them to notice more details about a person than somebody with less skill. An average individual might describe someone as “friendly,” while the person with higher interpersonal cognitive complexity will notice that they are also giving and self-confident.

Uses of Cognitive Complexity Theory

As mentioned previously, cognitive complexity is a topic that is used in software development to describe how complex a given piece of code is. However, it is also used to design computers that think more as humans do. Computers process information through binary code, or ones and zeroes. They see the program to execute, and they do it. They do not pause for consideration or come up with creative solutions. So, software engineers and scientists are trying to develop ways in which a computer can think more like a human to solve more complex problems. These systems are called artificial intelligence. Artificial intelligence aims to develop computers capable of complex cognitive functions rather than simple functions like memory and perception. Teaching computers to see the nuances in different problems allows them to handle more complex situations in more optimal ways, rather than approaching a problem head-on in the most direct path.

In organizations, cognitive complexity refers to the ability of people to notice patterns in their organization so that they can optimize processes for efficiency. This capability requires seeing the organization in a broad sense and a specific one. Optimizing one part of an organization is a much simpler feat, where there are fewer variables to consider. Optimizing an entire organization requires the ability to see any potential bottlenecks, understand supply and demand, know market trends, and much more. If a company is underperforming, leaders need to be able to recognize why it is happening and come up with solutions to the problem. Cognitive complexity allows people to think outside the box and develop creative solutions.

Read more here

Web Application Authentication

Launch browser. Enter username password. Log in. Done. How hard could it be? This is a challenge I run into when I talk about security and identity. My demos are so boring, because after all that jazz, you see “Hello username” written in Times New Roman. It really punctures the demo, doesn’t it?

As it turns out, authentication can be quite involved. And it’s still evolving every day because this boundary to your application is under duress, constantly, and our enemies are getting smarter. That’s what this article is about. And although I’ll talk generically and stick to general concepts, I’ll use Azure AD as an example.

A Long Time Ago

A long time ago when the internet was nascent, we used a text-based browser called Lynx. There were other mechanisms to access information on the internet too. There was this protocol called SMTP, which is still widely used today. Did you know that SMTP existed basically as an unauthenticated protocol for almost three decades? All it took was understanding the protocol and Telnetting to the SMTP server, and you could send email as anyone. Boy, did I have some fun with that.

I used to wonder, how could this be so simple? I could set up three email addresses, A, B, and C. A forwards to B and C. B forwards to A and C, and C being the email address. Now, I could just initiate an unauthenticated email to A, and C will get overwhelmed by email messages causing old-style DDOS (distributed denial of service), and you know what? It worked. This is how insecure the internet used to be not too long ago. Frankly, with a slight modification, you could defeat inboxes even today.

This is what keeps me up at night. The internet, still, feels very flimsy, and thanks to my unimpressive demos, almost nobody cares about security in a project. It’s all about deadlines and features, and security is just an inconvenience to get past.

A very long time ago, we invented an authentication protocol called basic authentication. This was just sending the username password over the wire in a header. We tried to secure it using HTTPS, but plenty of governments and organizations can sniff HTTPS traffic as a man-in-the-middle. So we came up with NT Lan Manager version 1 (NTLMv1), which was easily defeatable. Followed by NTLMv2, which was better and is still in wide usage today but has plenty of shortcomings. And perhaps the most common legacy protocol in widespread use today is Kerberos. Kerberos relies on a central authority and plenty of network chit chat, so it didn’t scale to the internet.

As these dinosaur protocols roamed the earth, a meteorite called the internet came by to spoil their party. Organizations tried to solve the puzzle by using VPNs and trust relationships between active directories, but you can’t survive a direct hit from a meteorite like the internet. Well, to be precise, some dinosaurs survived. I mean we still have crocs and gators around us, right? Kerberos still has a place on your intranet. But we needed something different, something that focused on the internet.

WS-Fed and SAML

In the early 2000s, the WS-* standards started taking shape. One of these was WS-Fed, and with it came SAML, security assertion markup language. SAML is an XML packet format. In the early 2000s, accessing the internet was either through a website, i.e., a browser on your desktop, or via protocols such as FTP, Telnet, etc. It became clear that websites could offer value if we found a secure way for users to log in.

A post and redirect-based standard emerged, called WS-Fed. At a very high level, it separated the responsibility of the IdP (or identity provider), the entity that performs authentication, and the RP (or relying party), also known as service provider, which is the application you’re trying to access. The RP trusted the IdP and this trust was established using certificates. The idea was that the user lands on the RP, and the RP says, “hey, you aren’t authenticated, so please go here to prove who you are.” The user could optionally be given more than one choice of an IdP. The user goes to the IdP, proves who they are (via credentials such as username password or more), and the IdP sends back a SAML packet with enough information about the user that the RP can use to establish identity and proceed.

This “enough information” is the attributes about the user, also known as claims.

WS-Fed served us well for many years. One of the products that used it was SharePoint. As time progressed, the demands of applications increased. For instance, they expanded who could initiate an authentication. If the RP initiates an authentication…

… this article is continued online. Click here to continue.