One of my goals for this year is to establish a curriculum to help my team learn more about security testing. We’re developing our first cloud-hosted solution, and there are many elements of browser-based security testing that we’ve never experienced, so I’ve been hunting for articles that are easy to read and offer introductory material on security design.
A few days ago, a security article called “The Beer Drinker’s Guide to SAML” came up in a chat room I participate in. The topic looked fun and easy enough, so I read through it. The article explained that SAML — Security Assertion Markup Language — is the go-between for authentication providers and authentication consumers, much like a wristband used in a beer garden. The authentication provider identifies that you are eligible to receive services from a vendor (i.e., checks your ID and gives you a wristband to access the beer garden). The vendor, who is the authentication consumer, then provides services based on that SAML assertion from the provider, similar to how a beer vendor allows you to buy beer based on the presence of your wristband.
Excited by this introductory material, I decided to test my mastery. I immediately messaged our security guru to ask him whether our new project uses SAML. I wasn’t even sure I’d used the words correctly, but I was hoping the question I asked made sense. His response was, “Good question. I’m going over the security stack with another developer right now. You should really be in here. Come on over to the small conference room.”
My jaw dropped. I was only being cheeky with a newly discovered term, and now suddenly I was about to be immersed in language I wouldn’t understand in a room with two expert developers. There would probably be code involved. At first, I tried to back out with, “I only knew that term because I just read an article.” Luckily, the developer knew me well enough to push me a little, and I joined them.
Get TestRail FREE for 30 days!
A Token System
When I walked into the room, there were already a number of drawings on the whiteboard, but the one that remained up throughout the discussion looked a lot like the drawings from the article I had just read. But instead of two boxes representing the authentication provider and the authentication consumer, there were now three boxes: the authentication provider, the authentication consumer and the browser itself. I soon discovered that we do not use SAML, but we use an alternative with similar enough behavior that most of what I read still applies. Ultimately, it’s all about having a token that says who you are and what you can do, having an authentication provider that provides that token, and having a product that consumes the token.
As we walked through the technical stack, we did end up looking at code. They showed me the algorithm where we start interpreting the token that was received in order to decide what permissions a user has in our program. The developer pointed out something interesting. Right now, we only have two types of user: basic or admin. In the future, we will probably have many types of user, and we plan to introduce new modules that will be restricted to specific subsets of user. That means that every time a new role is introduced, this code will need to be updated to make sure each new type of user has access to what they need.
Looking at the code, I could see how it would be easy to neglect adding a certain role to a certain set of permissions. I mentioned it, and they responded that we might alter the algorithm once we have to deal with the more complex set of permissions rules. Even so, I made a note of how we’re handling permissions now, so I can write a charter about checking a set of user types against each set of permissions. You never know if that code is going to stick around or not, and this way we’ll be ready if the old code is what we have to test against.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Swimming in the Deep End
Even though I was fearful, I’m glad I overcame my fears and joined the developers in their review of the security stack. Reviewing the code wasn’t as scary as I thought. Even though a few things they discussed went over my head, I was surprised by how much I understood. I came out of the meeting with new respect for how difficult it is to implement a security system, as well as some self-confidence in my ability to understand technical information. Sometimes you need to take a surprise jump in the deep end to discover how well you can swim.
This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
Test Automation – Anywhere, Anytime
