Subtitles of the Movie

This is Citrix Access Gateway Advanced Edition 4.5 and in this video we're going to discuss Web resources. Now as you'll recall Web Resources are objects that you as a Citrix Administrator will set up to allow your end users secure access to both internal and external web sites. Now these websites can be anything accessible on the Internet or they can be intranet sites that are only accessible to a small group of users and we'll go over elsewhere in the course how to set up policies and access lists so that only certain users can access certain resources. I mean of course we'll tie all of this together in the lab. So we'll go into the Access Management Console and we're brought to the last view that we opened. In this case I have already pre-selected the Web Resources View; obviously there are no Web Resources right now. So we'll right click and we'll choose Create Web Resource, obviously as with anything you'll create you'll have to give it a name and a brief description. In this case I'll fill in both of those. We'll name our Web Resources the Google Search Engine and we'll give it access to Google. In this particular Web Resources it's going to be just a simple website, so we'll hit Next and we're brought to the Addresses Screen. Now you'll notice that you can specify multiple urls in the Addresses Screen and this is simply so you can have a single Web Resources that is published to your end users that allows access to, in our case anything that's at Google. However if you were to click one of the search results that you get back from searching Google you would be presented with an access denied screen simply because you're not allowing access to any other websites other then Google.com inside this Web Resource. So let's go ahead and click New to add a New URL. In the URL Box up here we'll enter www.google.com and we'll drop down the application type, we'll go over the different types of applications. We have a Citrix Web Interface 4.2 or later, we'll create one of those Web Resources as well just so you can see how they both look. We have SharePoint and then we have SharePoint with Web Interface Web Part. The only difference between these two is that there is a company that makes Web Parts a snap in to the SharePoint Framework that allows you to get information from your Citrix Presentation Server Web Interface. We won't be setting up either one of these in this course, simply because we don't have a SharePoint Server on our lab network. The last option we have is for Web Application, now Web Application that requires session cookies. Again these are both the same, the only difference is that if you have a website that requires a log in and you have to have a session cookie to hold that log in such as shopping cart on an E-Commerce site, you would want to choose the second option, most of the time you'll be choosing Web Application which is what we'll do for this demonstration. Now when you set up a Web Resource you can also choose the authentication type which is used to pass user credentials to websites. When no authentication type is selected the default Settings is that the Web Resource does not pass the user credentials to the website, again this is the default setting and with this method users must explicitly log onto websites. For example if a website uses form based authentication the user can access the log on page for a website but must provide credentials to access the website. There are three supported authentication types, the first one should never, ever, ever be used unless it is the only thing that the target website accepts and that is the basic authentication. Basic Authentication stores the users' credentials on the web server in encrypted format and it passes those credentials in the conduit to the website in plain text with every request. The operative word in that sentence is in plain text, meaning that if someone has a protocol analyzer between you and the Secure Access Server or between the Secure Access Server and the Web Server on the other end they could sniff out your Domain Credentials from the HTTP stream and use them for whatever nefarious purposes they so desired. This is so insecure that in fact if you check this basic box it tells you basic authentication allows users primary credentials to be sent in clear text, are you sure? In this case we'll say No because we're not actually going to turn that on. The second option for authentication is Digest Authentication. Digest Authentication still passes the user credentials to the remote website but it does it using an MD5 Digest which is an encryption algorithm that protects these credentials from just being pulled off the wire in a plain text format. You can still pull the credentials off the wire but unfortunately you'd need an inconvenient few years to decrypt it by which point hopefully those credentials are not valid anymore. The last option is for Integrated Windows Authentication, Windows Authentication Hashes the Active Directory Credentials of a user using NTLN or Kerbos and passes them to the remote website. In this case the user is not explicitly asked for authentication, it just kind of happens if you happen to be an authorized user of the website. What's important to remember is that the setting you choose on here will be determined by the remote website. If the remote website only supports basic authentication and you choose integrated windows its not going to work because the remote website doesn't understand integrated windows authentication. In this case since Google does not require any type of authentication, we'll just hit OK and we're taken back to the Configure Addresses Screen.