Re: [Dev] [IS] Using unregistered realm in PassiveSTS request

[Hasanthi Purnima Dissanayake]

Hi,

This is regarding the passive sts logout scenario which is mentioned in
[1]. According to the specification [2] in Sign-Out Request Syntax part it
has mentioned to use the 'wsreply' parameter if it is specified and to use
realm-specified if it is not specified. But when considering the security
considerations mentioned in the section 8 of [2] it is  RECOMMENDED that
the Identity Provider should  verify the 'wsreply' url. So we decided to
redirect the logout request to the 'wsreply' url configured in Identity
Provider side in the case if the 'wsreply' url we get from the request and
the url configured in the Identity Provider are different.

Further as Chamara mentioned above, at the moment we don't expect wtreply
must be a sub domain of wtrealm as mentioned in the specification.

[1] https://wso2.org/jira/browse/IDENTITY-2835
[2]http://public.dhe.ibm.com/software/dw/specs/ws-fedpass/ws-fedpass.pdf

Thanks




Hasanthi Dissanayake

Software Engineer | WSO2

E: hasan...@wso2.com 
M :0718407133| http://wso2.com 

On Thu, Oct 8, 2015 at 12:01 PM, Chamara Philips  wrote:

> Hi,
>
> This is regarding [1] .
> Currently when we send an unregistered realm or no realm with the
> parameter 'wtrealm' in the Passive STS request, we receive the same
> response as it is with the correct realm, but without the claim attributes.
> When an unregistered realm is passed a log is printed at back-end
> from RegistryBasedTrustedServiceStore. This is the expected behavior at the
> moment.
> The specification at [2]
> ,
> doesn't specify what to do when a invalid 'wtrealm' is passed. How ever
> according to [2]
>  both
> the 'wtreply' and 'wtrealm' are optional parameters. In section 8 in [2]
> ,
> as security concerns, there is a possibility of man-in-the -middle-attack
> when the Identity Provider doesn't verify whether the 'wtreply' is same or
> is in 'wtrealm'. The following part is quoted from [2]
> .
>
>
> [Man-in-the-Middle attacks: The wtreply must be in wtrealm (i.e., the same
> URL, or, e.g., wtreply is a host within the domain of wtrealm). It is
> strongly RECOMMENDED that the Identity Provider verifies this, and that
> wtreply is an valid HTTP/S address.
>
> • The wtrealm SHOULD be a security realm of the resource in which nobody
> can control URLs.
>
> • For Kerberos tokens the key distribution SHOULD distribute correct
> realms for the keys, so that Identity Providers know what the correct
> realms are for keys that they use.
>
> • For SAML tokens the resource SHOULD verify that exactly this realm is in
> one of the two (fix one!) fields of the ticket.
>
> • For other token types similar considerations SHOULD be made before using
> them.
>
> It is strongly RECOMMENDED that the resourceSTS secure information or use
> HTTP/S or some other transport-level security mechanism for all
> communications. ]
>
> As far as I understand the behavior when an unregistered realm is passed
> in request, is OK according to the spec [2]
> .
> Though we don't support the verification of 'wtreply' and 'wtrealm' as
> described in spec [2]
> 
> at the moment, we can enforce to verify the provided 'wtreply' in the
> request to be similar to the provided 'Passive STS WReply URL' when
> registering the Service Provider in IS. If they are not similar the user
> will be redirected to the given 'Passive STS WReply URL'.
>
> As far as I understand overall realm validation workflow is ok to proceed.
> Any suggestions on any improvement are welcome.
>
> [1] https://wso2.org/jira/browse/IDENTITY-2803
> 
> [2] http://public.dhe.ibm.com/software/dw/specs/ws-fedpass/ws-fedpass.pdf
>
> Thank you.
> --
> Hareendra Chamara Philips
> *Software  Engineer*
> Mobile : +94 (0) 767 184161 <%2B94%20%280%29%20773%20451194>
> chama...@wso2.com 
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IS] Using unregistered realm in PassiveSTS request

[Chamara Philips]

Hi,

This is regarding [1] .
Currently when we send an unregistered realm or no realm with the parameter
'wtrealm' in the Passive STS request, we receive the same response as it is
with the correct realm, but without the claim attributes.
When an unregistered realm is passed a log is printed at back-end
from RegistryBasedTrustedServiceStore. This is the expected behavior at the
moment.
The specification at [2]
,
doesn't specify what to do when a invalid 'wtrealm' is passed. How ever
according to [2]
 both
the 'wtreply' and 'wtrealm' are optional parameters. In section 8 in [2]
, as
security concerns, there is a possibility of man-in-the -middle-attack when
the Identity Provider doesn't verify whether the 'wtreply' is same or is in
'wtrealm'. The following part is quoted from [2]
.


[Man-in-the-Middle attacks: The wtreply must be in wtrealm (i.e., the same
URL, or, e.g., wtreply is a host within the domain of wtrealm). It is
strongly RECOMMENDED that the Identity Provider verifies this, and that
wtreply is an valid HTTP/S address.

• The wtrealm SHOULD be a security realm of the resource in which nobody
can control URLs.

• For Kerberos tokens the key distribution SHOULD distribute correct realms
for the keys, so that Identity Providers know what the correct realms are
for keys that they use.

• For SAML tokens the resource SHOULD verify that exactly this realm is in
one of the two (fix one!) fields of the ticket.

• For other token types similar considerations SHOULD be made before using
them.

It is strongly RECOMMENDED that the resourceSTS secure information or use
HTTP/S or some other transport-level security mechanism for all
communications. ]

As far as I understand the behavior when an unregistered realm is passed in
request, is OK according to the spec [2]
.
Though we don't support the verification of 'wtreply' and 'wtrealm' as
described in spec [2]
 at
the moment, we can enforce to verify the provided 'wtreply' in the request
to be similar to the provided 'Passive STS WReply URL' when registering the
Service Provider in IS. If they are not similar the user will be redirected
to the given 'Passive STS WReply URL'.

As far as I understand overall realm validation workflow is ok to proceed.
Any suggestions on any improvement are welcome.

[1] https://wso2.org/jira/browse/IDENTITY-2803

[2] http://public.dhe.ibm.com/software/dw/specs/ws-fedpass/ws-fedpass.pdf

Thank you.
-- 
Hareendra Chamara Philips
*Software  Engineer*
Mobile : +94 (0) 767 184161 <%2B94%20%280%29%20773%20451194>
chama...@wso2.com 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev