When publishing applications, the number of applications is not limited beyond the hardware capabilities of the server, though one should consider general User-Interface design considerations. Creating a huge page with dozens of buttons is cool, in some people's opinion, but a general approach says that having no more than eight items on any menu is a good practice. This number is not set in stone, and you can always create some folders and divide the applications logically between them. Another thing to keep in mind is that the applications you define on a trunk will be displayed on-screen arranged from left to right, and from top to bottom, alphabetically. If it's important to you to have the applications appear in a certain order, the only means of controlling that is by naming them in a way that will force UAG to sort them to your liking. For example, you could name all RDP related applications with the prefix RDP ("RDP Exchange", "RDP SQL", and so on), so these will be grouped together, or have each application name start with a number. Another thing you can do to make things easier for users is to assign specific icons that differ from the default, to an application. This book is not about usability or user interface design, however, so let's go on.
Technically, you should be aware of one important fact. UAG has a security mechanism for web publishing that inspects the HTTP requests sent by clients to UAG and decides if these should be sent to backend web applications. This is very useful for several reasons:
- It allows you to block access to parts of the applications that you don't want people to use, such as the part that manages settings, or the part that controls the applications' permissions and authorization.
- It allows you to block specific commands or parameters that might be undesirable or dangerous. For example, certain URL parameters can be blocked in a way that prevents OWA (Outlook Web Access) users from uploading or downloading attachments.
- It allows you to block URL and parameter combinations that pose a risk, such as cross-site scripting or attacks that exploit faulty input validations in applications.
The access rules mechanism is controlled using the Trunk Configuration URL Set tab, which will be discussed in Chapter 10.
Note
What you do need to realize now, though, is that the rules are named and applied according to an application's type, which is determined by the template you select. Most templates have a fixed type, but the generic templates allow you to enter anything you want as the type. What's important to remember here is that if you publish multiple applications with the same type, the same access rules will apply to all of them. This could be a good idea and a time saver if you do indeed need all these applications to have the same level of access but, if not, you must keep this trinket of information in mind.
