Jerry Brightbill — Alpha Five Version 8

Complete Transcript of Interview

Let's Talk Computers Radio Talk Show

Host Alan Ashendorf

December 30, 2006

Alan: Today on Lets Talk Computers, we are going to be talking about web programming, and especially security with web programming and why it is so difficult to implement.

Our guest today is Jerry Brightbill, System Developer with Alpha Software. And welcome to Lets Talk Computers, Jerry.

Jerry: It's a pleasure to be here.

Alan: Working with web applications and building an application, you have to design the forms and then you have the code behind the forms. You have to have the backend; the database and you have to constantly be testing out the application. Most programmers look at it and say, "Let's get the application up and running and then we will make sure it is really secure." Is that the way it works?

Jerry: Usually, it does. Because the security is not thought of in the initial stages, it does become an add-on later. That brings with it a lot of problems because you may forget to design for security, or you may forget to apply security. Web applications in particular are built page-by-page, rather than as an integrated whole, and for that reason it is very easy to forget a page.

Alan: When you are talking about application security — and I'm going to put it on a network — almost all the people who are going to using it are going to be trusted employees. If something shows up that shouldn't show up or a particular part of the application becomes available that should not — in most cases, Mary is going to go and tap somebody on the shoulder and say, "I have access to this and I don't think I need to" and it is going to be fixed.

But on a web application, because you cannot control who will be seeing it, once you have been "mooned", you've been mooned, haven't you?

Jerry: It's the problem, because people who are accustomed to developing on the desktop can control access. When you are developing on the web, you can't control access. There is a misconception by many developers that if they control access to a main page for instance, they are then controlling access to all the other pages. Unfortunately, on a web application every page is available by its own URL and it is quite easy for a user, after they have been into a system, to go directly to a page and skip the main entry. And that is a problem. If you're assuming you're controlling entry from the main page, you are not when you're in a web app.

Alan: Having security built into a web application is not just whether we have access to the form, it is who and at what level we have access to the form. Because, let's look at Mary's access. She's basically clerical and all she needs to proof things and maybe change a couple of fields. But Ralph, the Administrator, really needs to be able to get all the information to change any and every field. Those are fields that Mary should not ever have to touch.

Jerry: One of the problems that sometimes occur is that developers do not think about restricting access within a page. One of the solutions that is commonly applied is to build two pages — one page for one user and one page for another user. That makes maintenance later very difficult, because you are now maintaining two pages, or three, or four, when you really should only be maintaining one. By using a proper security system you can limit access within a page, as well as the page itself.

Alan: When adding the security after the fact, we are trying to shoe-horn something in to a program that's already working. We then take a really good chance of breaking something that is already working, just by adding extra code to it, to make it more secure.

Jerry: When you are adding it (security) after the fact, you have a very good chance of forgetting to add it or adding it inappropriately. You are not designing for security - you are adding security later. As I mentioned, one of the common ways of doing that is, rather than fixing a page, is build a new page and strip out the things you don't want to show. But that again brings in a lot more work and is much less efficient.

Alan: In Alpha Five Version 8, you have added a Web Security Framework that works behind the scenes and for every page, every form. It makes it seamless, doesn't it?

Jerry: The idea behind the Alpha Five Web Security System is that one of the key features is that it is built into the Server System. Therefore, every page request, every file request is checked by the Security System. That is already built in. With the Security System, which is very easy to configure, we can also apply security within the components in Alpha.

Alan: Does that mean that we have a lot of extra code in order to implement the Web Security System Framework?

Jerry: It's all built-in. The Security System in the server is already built into the server; that's automatic. It's turned on and off by a simple check box. All the supporting code is pre-written so that it doesn't require the user to write anything. In fact, to apply security is very simple.

One of our goals was to make it as simple as possible. Basically, it starts out by opening up a Parameters Form, where you can select the various security options that you want. That's simply done with check boxes and drop-downs. It is all very simple. Once all the Parameters are set, all the supporting code in the background already exists and is ready to run.

Alan: You brought up a point earlier, that if you know how to get to the web page, in most cases you by-pass security. But, in this case, it really doesn't make any difference, because if you try to go to that web page, you are going to get an automatic security check, aren't you?

Jerry: The way the Security Service System works, is that every page request that comes to the server then goes through the Security System and is checked against the settings that have been saved. Once we set the basic parameters for security, we can then apply security at the page level. Every page can be assigned as either "Denied", which is denied to everyone, or we can set a page to be "Allowed", which is allowed by everyone, or we can set a page to be allowed by "login". If it's allowed by login, the user must log into the system. They then become a member of a Security Group. Certain Groups are allowed to see certain pages, certain Groups are not. If the user requests the page and they are not logged in, they are then redirected back to a specified page, which is part of the settings.

Alan: Mary is basically just one of about six different people in her department. Do we have to set up a separate security for Mary, for Betty or can we put them into a Group?

Jerry: The way the Security set up, we define Security Groups, which are Membership Groups. We can set up one Group, two Groups, as many Groups as we want. In the set-up forms that we have, we have a Users and Groups Form that we can open. In that form, we can assign various Groups. We can have a Group for Accounting, for Marketing, and we can have an Administrator Group. Once the Groups are defined, we then can add Users to the System.

A User then becomes a Member of a Group. For example, when we set Security on a page, the page is set by the security of the Group that's allowed to see it .For instance, on one page, the Account Group may be able to see it. Another page, we may allow Accounting, Marketing, Sales - all of them to see it. Any User, when he is a member of that Group, will be able to see that page.

Alan: We can actually set up by someone's login, as to which page they would actually go to and which fields that we would see on their Form?

Jerry: Depending on the Security Parameters that are set up initially, they can be set that, at login, the User can go to a specific page or they can go to a page that is defined for them specifically. For example, Joe may, after login, be directed to a specific page that is saved in his Security Settings, or he may go to a generic page that everyone sees. Once they go to a page, we can have multiple Groups that can see that page. It may not be restricted, for instance, to Accounting.

Alan: I know as a programmer, myself, to put the security after the fact it usually ends up being a total nightmare because you are having to code if then or case statements where each particular department or each particular Group or each particular person and end up coding by what they call "exception" and before you know it, you have such a hodge-podge of uncontrollable, unmodifiable and unmaintainable code that you might as well start all over again.

Jerry: One of the problems in doing it after the fact is that if you wish to add a Group for instance, it is very difficult if you have already hard-coded all the Groups into the system. Because this system is based on a table structure, where we save the Users, the Groups, and their Permissions within the Groups, we can add a Group very easily.

One of the advantages of this particular System occurs when we make a change to Security Settings — if we add a Group, or we change the way the Security operates. When we publish that, it becomes published as part of the page folder. The next page request that comes into the System will use the new settings automatically. So we can add a Group or add a User and the very next time the page request comes in, it will use these new settings. We don't have to re-code pages or anything else.

Alan: I guess the question that it comes down to, is how secure is the Web Security Framework that is built into Alpha Five Version 8? Is this Mission Critical? As you pointed out, anybody can have access to a web page anywhere in the world and once the data gets out — Oops! It's a little bit too late to pull it back. How secure is this?

Jerry: Because it was built into the Server System, every page, every file request - and that includes JavaScript files, CSS (Cascading Style Sheets) files, images — all of them are checked against the Security. When Security is checked, a couple of things are loaded into memory from the server. We load a list of all the pages that are available. We load in all the Security for those pages We can set Security for each page or we can set Security by File Type. For instance, we can allow all JavaScript files. What happens when a page request comes in, if you have a page that has JavaScript, Style Sheets, or images, every single one of those components is checked against that Security. And because it is built into the Server System, there is no way to get around it. So, every File Request that comes in is checked against the Security, automatically, in the background.

Alan: Putting the security in as a Framework before we even start coding, this means that maintenance of this System is a lot easier after the fact. To me, the most important thing is maintaining the code months or years later. If you have to go back and do complete re-writes because now I want to change something, that's not writing efficient code.

Jerry: No, it isn't efficient. One of the advantages of this particular system is that security can be set up very early in the process. In fact, the security can be set up after we have one page defined. Part of the security setting requires that we have what we call Redirect Pages. If a User tries to access a system that requires a login, we have to redirect them. We can apply security as soon as one page has been defined in the particular project. Then we can set up all of our Security Settings. We can add pages and set up their groups very early in the process. They can be modified later, very simply, just by check boxes and making new selections.

Alan: Well, I know that more businesses are going online, where they are actually putting their full network applications online and they don't really realize how vulnerable they can be by doing that. This way, they don't really have to think about it, because it is secure, from the get-go.

Jerry: That's the advantage because it requires no coding, it's very simple to apply, it can be done with three basic forms. It can be configured very quickly. And then it can be applied to everything.

Alan: We were talking about having the web application secure from form to form. But, a lot of times, we want to get down to the control level. And that's what most programmers really have a hard time. And this is already built-in.

Jerry: It's already built into the System. In the Alpha Five Version 8 System, we have component builders, which allow us to build grids and dialogues and so on. And within those component builders, the security is already activated. For example, we can set up controls that are available to only certain Groups. And because we can develop the security very early in the process, we will know that security when we are building components. It could also be added later.

For instance, if we wish to set up certain users that are allowed to only delete records, we may restrict deletion to certain groups. Certain groups may be restricted to just viewing records, others to adding records. We can build this all into the Component Builder and select the Groups as we build the component. It makes it very easy — and very easy to change later.

Alan: Because you can go to the Alpha website and see actual applications that other people have written and they have the full applications up there on their website.

Jerry: In some cases, they do. Also Alpha Five Version 8 does ship with a number of sample applications — one of which is called Web Applications Demo. It has demonstration pages and components with a whole security setup. All the pages that are available in the demos have all the supporting code and all the supporting information behind, as well as descriptions.

Alan: Well, I know that you have written a lot of web applications. Would you ever go back to writing it the way that we used to do?

Jerry: I would certainly hope not. One of the goals in developing this, particularly on security side to create an application that would be very user friendly, was to take a look at what is already out there on web security as far as features. The idea behind the Alpha Five Version 8 Web Security was to include as many features as possible. Obviously, it can also be turned on and turned off. It includes just about every web security feature that we could find that was used on a common basis. Because of that, it makes it very easy to set up. From a beginner's standpoint, a beginner can set up web security in under ten minutes.

Alan: Jerry, it has been our pleasure to have you as our guest at Let's Talk Computers, talking about how we can make our web applications secure — right out of the box. And we hope to have you back again, talking about other exciting new announcements.

Jerry: It's been a pleasure.