Programmatic Access to SP Attributes

[Cantor, Scott]

>  My page is a single ASP .NET page (Default.aspx with
> Default.aspx.vb code behind) that resides on IIS at
> http://localhost:8101/secure/Default.aspx.

That's not ideal on any number of levels. If you don't have experience, the worst thing you can do is use bogus names and ports, it's going to make your life much harder.

But if that's the case, then you have a number of issues to fix.

> So in my shibboleth2.xml, I set this in the ISAPI section:
> 
> <Site id="1" name="localhost" port="80" />
> <Site id="3" name="localhost" port="8101"/>

That means you can't access these from off the machine, so don't try. Assuming you understand that, then you also have to recognize that these are the two sites in use, and that's all. They may or may not be SSL enabled, but you can't be using other ports, like 443, or it will ignore them, as it is in fact doing.

> Then I have this in my RequestMap section:
> 
> <Host name="localhost" port="80">
> 	<Path name="secure" authType="shibboleth" requireSession="true"
> />
> </Host>
> <Host name="localhost" port="8101"  redirectToSSL="443" >
>         <Path name="secure" authType="shibboleth" requireSession="true"/>
> </Host>

So, you have a redirect to an SSL server on port 443. That ain't gonna work.

Secondly, you don't need the complexity here. One Host, take out the port, and let it map all requests to /secure on any protected site to get handled this way. Or if you really want only the port 8101 resources protected take out the first Host.

In your case, you clearly have https running on 443, so that is the actual resource at issue.
 
> When I hit the page http://localhost:8101/secure/Default.aspx, I get taken
> directly to the page.  The native.log shows these entries:

And you have no content rules protecting that port. It's https, so the port is 443, and you have carved that out as unprotected.

> Now where I get confused is that if I hit the /Login directly, everything
> seems to work exactly like it should.

Requesting a session manually has no connection to protecting resources.

> Is this just evidence that I've messed up the site protection
> piece, but otherwise it works?

Yes.

-- Scott