URL access given to Protected page by Shibboleth Service Provider

[Cantor, Scott]

On 6/23/14, 3:16 PM, "anupam.nandan at gmail.com" <anupam.nandan at gmail.com>
wrote:
>
>But, on the same browser if the user manually changes the URL from
>http://localhost/test to  http://localhost/test2 and hits the enter then
>Shibboleth SP gives access to that page as well without taking user to the
>IDP. (which is not expected)

It's quite expected.

>Moreover, if the same user punches the URL(cut the URL and paste it to the
>browser )   http://localhost/test2 and then tries to access it then in
>this
>case shibboleth SP takes the user to the IDP. (which is expected)

That's not only not expected, it's physically impossible. You're mistaken
about one of those claims, or you're dumping the session in between.

>Below is my RequestMapper in Shibboleth2.xml file :

So, that doesn't work.

>            <Path name="test" authType="shibboleth" requireSession="true"
>forceAuthn= "true"
>authnContextClassRef="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800
>-63:1"/>

Those properties only apply to the manner in which a session gets
requested, they aren't authorization rules. If you want to do
authorization, you need to *do* that, but that isn't functionally
authorization.

See 
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPXMLAccessContr
ol

The example actually shows a policy related to checking the context class.

Generally speaking, you need application intelligence to make this kind of
use case workable. Just blocking access won't give you a reasonable user
experience.

-- Scott