From bburke at redhat.com  Mon May  5 18:55:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 05 May 2014 18:55:44 -0400
Subject: [security-dev] CSRF and json
Message-ID: <536816F0.4040008@redhat.com>

If you have a JSON based web-service is it still vulnerable to CSRF 
requests?  CORS should be one protection.  For cross domain FORM posts, 
if the json service checks the media type for application/json it should 
abort the request, correct?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Mon May  5 22:25:19 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 5 May 2014 23:25:19 -0300
Subject: [security-dev] CSRF and json
In-Reply-To: <536816F0.4040008@redhat.com>
References: <536816F0.4040008@redhat.com>
Message-ID: <20140506022519.GA72025@abstractj.org>

Good morning Bill

On 2014-05-05, Bill Burke wrote:
> If you have a JSON based web-service is it still vulnerable to CSRF
> requests?  CORS should be one protection.  For cross domain FORM posts,

They are, if you don't have checks for the content type.

> if the json service checks the media type for application/json it should
> abort the request, correct?

If you want to follow strictly the specification
(http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
yes, they just abort with "network error".

If you want to mitigate CSRF and other web vulnerabilities, my suggestion
is the CSP specification (http://www.w3.org/TR/CSP11/).


>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev

--

abstractj

From psilva at redhat.com  Tue May  6 08:27:30 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 May 2014 08:27:30 -0400 (EDT)
Subject: [security-dev] CSRF and json
In-Reply-To: <20140506022519.GA72025@abstractj.org>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
Message-ID: <894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>

Also, one of the most popular protection is a CSRF Token. This page can be useful.

https://developer.mozilla.org/en/Persona/Security_Considerations

----- Original Message -----
From: "Bruno Oliveira" <bruno at abstractj.org>
To: "Bill Burke" <bburke at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Monday, May 5, 2014 11:25:19 PM
Subject: Re: [security-dev] CSRF and json

Good morning Bill

On 2014-05-05, Bill Burke wrote:
> If you have a JSON based web-service is it still vulnerable to CSRF
> requests?  CORS should be one protection.  For cross domain FORM posts,

They are, if you don't have checks for the content type.

> if the json service checks the media type for application/json it should
> abort the request, correct?

If you want to follow strictly the specification
(http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
yes, they just abort with "network error".

If you want to mitigate CSRF and other web vulnerabilities, my suggestion
is the CSP specification (http://www.w3.org/TR/CSP11/).


>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev

--

abstractj
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev

From bburke at redhat.com  Tue May  6 08:37:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 08:37:18 -0400
Subject: [security-dev] CSRF and json
In-Reply-To: <894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
	<894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
Message-ID: <5368D77E.9060503@redhat.com>

Yeah, knew about the token.  Was looking to avoid using it though.

On 5/6/2014 8:27 AM, Pedro Igor Silva wrote:
> Also, one of the most popular protection is a CSRF Token. This page can be useful.
>
> https://developer.mozilla.org/en/Persona/Security_Considerations
>
> ----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: security-dev at lists.jboss.org
> Sent: Monday, May 5, 2014 11:25:19 PM
> Subject: Re: [security-dev] CSRF and json
>
> Good morning Bill
>
> On 2014-05-05, Bill Burke wrote:
>> If you have a JSON based web-service is it still vulnerable to CSRF
>> requests?  CORS should be one protection.  For cross domain FORM posts,
>
> They are, if you don't have checks for the content type.
>
>> if the json service checks the media type for application/json it should
>> abort the request, correct?
>
> If you want to follow strictly the specification
> (http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
> yes, they just abort with "network error".
>
> If you want to mitigate CSRF and other web vulnerabilities, my suggestion
> is the CSP specification (http://www.w3.org/TR/CSP11/).
>
>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
> --
>
> abstractj
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Tue May  6 09:27:18 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 May 2014 09:27:18 -0400 (EDT)
Subject: [security-dev] CSRF and json
In-Reply-To: <5368D77E.9060503@redhat.com>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
	<894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
	<5368D77E.9060503@redhat.com>
Message-ID: <1264398152.1333077.1399382838484.JavaMail.zimbra@redhat.com>

I see. IMO, check the content type makes more difficult because the content type would be text/plain or any other. But you`re still vulnerable.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
Cc: security-dev at lists.jboss.org
Sent: Tuesday, May 6, 2014 9:37:18 AM
Subject: Re: [security-dev] CSRF and json

Yeah, knew about the token.  Was looking to avoid using it though.

On 5/6/2014 8:27 AM, Pedro Igor Silva wrote:
> Also, one of the most popular protection is a CSRF Token. This page can be useful.
>
> https://developer.mozilla.org/en/Persona/Security_Considerations
>
> ----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: security-dev at lists.jboss.org
> Sent: Monday, May 5, 2014 11:25:19 PM
> Subject: Re: [security-dev] CSRF and json
>
> Good morning Bill
>
> On 2014-05-05, Bill Burke wrote:
>> If you have a JSON based web-service is it still vulnerable to CSRF
>> requests?  CORS should be one protection.  For cross domain FORM posts,
>
> They are, if you don't have checks for the content type.
>
>> if the json service checks the media type for application/json it should
>> abort the request, correct?
>
> If you want to follow strictly the specification
> (http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
> yes, they just abort with "network error".
>
> If you want to mitigate CSRF and other web vulnerabilities, my suggestion
> is the CSP specification (http://www.w3.org/TR/CSP11/).
>
>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
> --
>
> abstractj
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue May  6 09:39:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 09:39:41 -0400
Subject: [security-dev] CSRF and json
In-Reply-To: <1264398152.1333077.1399382838484.JavaMail.zimbra@redhat.com>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
	<894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
	<5368D77E.9060503@redhat.com>
	<1264398152.1333077.1399382838484.JavaMail.zimbra@redhat.com>
Message-ID: <5368E61D.70903@redhat.com>

Well, the endpoints are resteasy.  If the content-type is not 
application/json, then resteasy returns a 415.


On 5/6/2014 9:27 AM, Pedro Igor Silva wrote:
> I see. IMO, check the content type makes more difficult because the content type would be text/plain or any other. But you`re still vulnerable.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
> Cc: security-dev at lists.jboss.org
> Sent: Tuesday, May 6, 2014 9:37:18 AM
> Subject: Re: [security-dev] CSRF and json
>
> Yeah, knew about the token.  Was looking to avoid using it though.
>
> On 5/6/2014 8:27 AM, Pedro Igor Silva wrote:
>> Also, one of the most popular protection is a CSRF Token. This page can be useful.
>>
>> https://developer.mozilla.org/en/Persona/Security_Considerations
>>
>> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: security-dev at lists.jboss.org
>> Sent: Monday, May 5, 2014 11:25:19 PM
>> Subject: Re: [security-dev] CSRF and json
>>
>> Good morning Bill
>>
>> On 2014-05-05, Bill Burke wrote:
>>> If you have a JSON based web-service is it still vulnerable to CSRF
>>> requests?  CORS should be one protection.  For cross domain FORM posts,
>>
>> They are, if you don't have checks for the content type.
>>
>>> if the json service checks the media type for application/json it should
>>> abort the request, correct?
>>
>> If you want to follow strictly the specification
>> (http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
>> yes, they just abort with "network error".
>>
>> If you want to mitigate CSRF and other web vulnerabilities, my suggestion
>> is the CSP specification (http://www.w3.org/TR/CSP11/).
>>
>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Tue May  6 09:44:29 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 May 2014 09:44:29 -0400 (EDT)
Subject: [security-dev] CSRF and json
In-Reply-To: <5368E61D.70903@redhat.com>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
	<894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
	<5368D77E.9060503@redhat.com>
	<1264398152.1333077.1399382838484.JavaMail.zimbra@redhat.com>
	<5368E61D.70903@redhat.com>
Message-ID: <1484157244.1361166.1399383869671.JavaMail.zimbra@redhat.com>

But you can still forge the content-type, right ? XHR-based CSRF attacks ...

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "Bruno Oliveira" <bruno at abstractj.org>, security-dev at lists.jboss.org
Sent: Tuesday, May 6, 2014 10:39:41 AM
Subject: Re: [security-dev] CSRF and json

Well, the endpoints are resteasy.  If the content-type is not 
application/json, then resteasy returns a 415.


On 5/6/2014 9:27 AM, Pedro Igor Silva wrote:
> I see. IMO, check the content type makes more difficult because the content type would be text/plain or any other. But you`re still vulnerable.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
> Cc: security-dev at lists.jboss.org
> Sent: Tuesday, May 6, 2014 9:37:18 AM
> Subject: Re: [security-dev] CSRF and json
>
> Yeah, knew about the token.  Was looking to avoid using it though.
>
> On 5/6/2014 8:27 AM, Pedro Igor Silva wrote:
>> Also, one of the most popular protection is a CSRF Token. This page can be useful.
>>
>> https://developer.mozilla.org/en/Persona/Security_Considerations
>>
>> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: security-dev at lists.jboss.org
>> Sent: Monday, May 5, 2014 11:25:19 PM
>> Subject: Re: [security-dev] CSRF and json
>>
>> Good morning Bill
>>
>> On 2014-05-05, Bill Burke wrote:
>>> If you have a JSON based web-service is it still vulnerable to CSRF
>>> requests?  CORS should be one protection.  For cross domain FORM posts,
>>
>> They are, if you don't have checks for the content type.
>>
>>> if the json service checks the media type for application/json it should
>>> abort the request, correct?
>>
>> If you want to follow strictly the specification
>> (http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
>> yes, they just abort with "network error".
>>
>> If you want to mitigate CSRF and other web vulnerabilities, my suggestion
>> is the CSP specification (http://www.w3.org/TR/CSP11/).
>>
>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue May  6 09:48:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 May 2014 09:48:19 -0400
Subject: [security-dev] CSRF and json
In-Reply-To: <1484157244.1361166.1399383869671.JavaMail.zimbra@redhat.com>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
	<894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
	<5368D77E.9060503@redhat.com>
	<1264398152.1333077.1399382838484.JavaMail.zimbra@redhat.com>
	<5368E61D.70903@redhat.com>
	<1484157244.1361166.1399383869671.JavaMail.zimbra@redhat.com>
Message-ID: <5368E823.4030203@redhat.com>

Aren't XHR-based attacks covered by CORS?

On 5/6/2014 9:44 AM, Pedro Igor Silva wrote:
> But you can still forge the content-type, right ? XHR-based CSRF attacks ...
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Bruno Oliveira" <bruno at abstractj.org>, security-dev at lists.jboss.org
> Sent: Tuesday, May 6, 2014 10:39:41 AM
> Subject: Re: [security-dev] CSRF and json
>
> Well, the endpoints are resteasy.  If the content-type is not
> application/json, then resteasy returns a 415.
>
>
> On 5/6/2014 9:27 AM, Pedro Igor Silva wrote:
>> I see. IMO, check the content type makes more difficult because the content type would be text/plain or any other. But you`re still vulnerable.
>>
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
>> Cc: security-dev at lists.jboss.org
>> Sent: Tuesday, May 6, 2014 9:37:18 AM
>> Subject: Re: [security-dev] CSRF and json
>>
>> Yeah, knew about the token.  Was looking to avoid using it though.
>>
>> On 5/6/2014 8:27 AM, Pedro Igor Silva wrote:
>>> Also, one of the most popular protection is a CSRF Token. This page can be useful.
>>>
>>> https://developer.mozilla.org/en/Persona/Security_Considerations
>>>
>>> ----- Original Message -----
>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: security-dev at lists.jboss.org
>>> Sent: Monday, May 5, 2014 11:25:19 PM
>>> Subject: Re: [security-dev] CSRF and json
>>>
>>> Good morning Bill
>>>
>>> On 2014-05-05, Bill Burke wrote:
>>>> If you have a JSON based web-service is it still vulnerable to CSRF
>>>> requests?  CORS should be one protection.  For cross domain FORM posts,
>>>
>>> They are, if you don't have checks for the content type.
>>>
>>>> if the json service checks the media type for application/json it should
>>>> abort the request, correct?
>>>
>>> If you want to follow strictly the specification
>>> (http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
>>> yes, they just abort with "network error".
>>>
>>> If you want to mitigate CSRF and other web vulnerabilities, my suggestion
>>> is the CSP specification (http://www.w3.org/TR/CSP11/).
>>>
>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> security-dev mailing list
>>>> security-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>>> --
>>>
>>> abstractj
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Tue May  6 10:02:51 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 May 2014 10:02:51 -0400 (EDT)
Subject: [security-dev] CSRF and json
In-Reply-To: <5368E823.4030203@redhat.com>
References: <536816F0.4040008@redhat.com>
	<20140506022519.GA72025@abstractj.org>
	<894382884.1275889.1399379250964.JavaMail.zimbra@redhat.com>
	<5368D77E.9060503@redhat.com>
	<1264398152.1333077.1399382838484.JavaMail.zimbra@redhat.com>
	<5368E61D.70903@redhat.com>
	<1484157244.1361166.1399383869671.JavaMail.zimbra@redhat.com>
	<5368E823.4030203@redhat.com>
Message-ID: <1139685373.1387484.1399384971623.JavaMail.zimbra@redhat.com>

Yeah, XHR is subject to the browser Same-Origin policy. 

My point is that there is no 100% mitigation of the risk. Rely on multi layer security is always a good approach :)

    http://securesoftware.blogspot.com.br/2008/05/xhr-and-csrf.html

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "Bruno Oliveira" <bruno at abstractj.org>, security-dev at lists.jboss.org
Sent: Tuesday, May 6, 2014 10:48:19 AM
Subject: Re: [security-dev] CSRF and json

Aren't XHR-based attacks covered by CORS?

On 5/6/2014 9:44 AM, Pedro Igor Silva wrote:
> But you can still forge the content-type, right ? XHR-based CSRF attacks ...
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Bruno Oliveira" <bruno at abstractj.org>, security-dev at lists.jboss.org
> Sent: Tuesday, May 6, 2014 10:39:41 AM
> Subject: Re: [security-dev] CSRF and json
>
> Well, the endpoints are resteasy.  If the content-type is not
> application/json, then resteasy returns a 415.
>
>
> On 5/6/2014 9:27 AM, Pedro Igor Silva wrote:
>> I see. IMO, check the content type makes more difficult because the content type would be text/plain or any other. But you`re still vulnerable.
>>
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>
>> Cc: security-dev at lists.jboss.org
>> Sent: Tuesday, May 6, 2014 9:37:18 AM
>> Subject: Re: [security-dev] CSRF and json
>>
>> Yeah, knew about the token.  Was looking to avoid using it though.
>>
>> On 5/6/2014 8:27 AM, Pedro Igor Silva wrote:
>>> Also, one of the most popular protection is a CSRF Token. This page can be useful.
>>>
>>> https://developer.mozilla.org/en/Persona/Security_Considerations
>>>
>>> ----- Original Message -----
>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>> To: "Bill Burke" <bburke at redhat.com>
>>> Cc: security-dev at lists.jboss.org
>>> Sent: Monday, May 5, 2014 11:25:19 PM
>>> Subject: Re: [security-dev] CSRF and json
>>>
>>> Good morning Bill
>>>
>>> On 2014-05-05, Bill Burke wrote:
>>>> If you have a JSON based web-service is it still vulnerable to CSRF
>>>> requests?  CORS should be one protection.  For cross domain FORM posts,
>>>
>>> They are, if you don't have checks for the content type.
>>>
>>>> if the json service checks the media type for application/json it should
>>>> abort the request, correct?
>>>
>>> If you want to follow strictly the specification
>>> (http://www.w3.org/TR/cors/#cross-origin-request-status). I would say,
>>> yes, they just abort with "network error".
>>>
>>> If you want to mitigate CSRF and other web vulnerabilities, my suggestion
>>> is the CSP specification (http://www.w3.org/TR/CSP11/).
>>>
>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> security-dev mailing list
>>>> security-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>>> --
>>>
>>> abstractj
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Wed May  7 10:23:59 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Wed, 07 May 2014 09:23:59 -0500
Subject: [security-dev] JSON Security Presentation from Brian Campbell
Message-ID: <536A41FF.2000009@redhat.com>

http://www.slideshare.net/briandavidcampbell/jose-can-you-see-34360871



From sbryzak at redhat.com  Thu May  8 20:36:43 2014
From: sbryzak at redhat.com (Shane Bryzak)
Date: Fri, 09 May 2014 10:36:43 +1000
Subject: [security-dev] PicketLink Deep Dive Part 2
Message-ID: <536C231B.20409@redhat.com>

http://in.relation.to/Bloggers/PicketLinkDeepDivePart2

From psilva at redhat.com  Thu May  8 21:18:37 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 8 May 2014 21:18:37 -0400 (EDT)
Subject: [security-dev] PicketLink Deep Dive Part 2
In-Reply-To: <536C231B.20409@redhat.com>
References: <536C231B.20409@redhat.com>
Message-ID: <1806052002.3060339.1399598317422.JavaMail.zimbra@redhat.com>

Awesome.

Going to update our site with both articles (1 and 2).

----- Original Message -----
From: "Shane Bryzak" <sbryzak at redhat.com>
To: security-dev at lists.jboss.org
Sent: Thursday, May 8, 2014 9:36:43 PM
Subject: [security-dev] PicketLink Deep Dive Part 2

http://in.relation.to/Bloggers/PicketLinkDeepDivePart2
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev

From Anil.Saldhana at redhat.com  Thu May  8 21:55:05 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 08 May 2014 20:55:05 -0500
Subject: [security-dev] PicketLink Deep Dive Part 2
In-Reply-To: <1806052002.3060339.1399598317422.JavaMail.zimbra@redhat.com>
References: <536C231B.20409@redhat.com>
	<1806052002.3060339.1399598317422.JavaMail.zimbra@redhat.com>
Message-ID: <536C3579.2050102@redhat.com>

Fantastic Shane as always. :)

On 05/08/2014 08:18 PM, Pedro Igor Silva wrote:
> Awesome.
>
> Going to update our site with both articles (1 and 2).
>
> ----- Original Message -----
> From: "Shane Bryzak" <sbryzak at redhat.com>
> To: security-dev at lists.jboss.org
> Sent: Thursday, May 8, 2014 9:36:43 PM
> Subject: [security-dev] PicketLink Deep Dive Part 2
>
> http://in.relation.to/Bloggers/PicketLinkDeepDivePart2
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev


From Anil.Saldhana at redhat.com  Fri May  9 11:53:12 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 09 May 2014 10:53:12 -0500
Subject: [security-dev] JSON Benchmarks
Message-ID: <536CF9E8.5090505@redhat.com>

An article FYI: http://www.infoq.com/news/2014/05/jackson-founder-responds

From Anil.Saldhana at redhat.com  Tue May 13 11:00:54 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 13 May 2014 10:00:54 -0500
Subject: [security-dev] PicketLink Contribution from community volunteer: Max
Message-ID: <537233A6.3060704@redhat.com>

Hi all,
   Max is a PicketLink community volunteer. He initially had a question 
about using custom user types in PicketLink IDM.

Pedro worked with Max to convert Max's use case into an excellent 
quickstart/demo. Thanks to Max for the contribution.

https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-angularjs-rest

The quickstart has the following features:

    - Secure HTML5-based applications using AngularJS at the frontend
    - Secure RESTful endpoints based on RBAC and Security Annotations
    - Token-based Authentication using JSON Web Token and JSON Web Signature
    - Provide a custom credential type and handler
    - Provide your own types to represent your users

Regards,
Anil

From psilva at redhat.com  Tue May 13 11:20:45 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 13 May 2014 11:20:45 -0400 (EDT)
Subject: [security-dev] PicketLink Contribution from community
 volunteer: Max
In-Reply-To: <537233A6.3060704@redhat.com>
References: <537233A6.3060704@redhat.com>
Message-ID: <1099391728.5346242.1399994445585.JavaMail.zimbra@redhat.com>

This is also an excellent example about how users can link their entity model (business model) with an identity model managed by PicketLink.

If you take a look closer, you'll notice that every time you create an user you associate a Person instance with him.

    https://github.com/jboss-developer/jboss-picketlink-quickstarts/blob/master/picketlink-angularjs-rest/src/main/java/com/gr/project/security/model/MyUser.java#L65

When returning users instances, the associated Person instance will always be retrieved to.

----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
To: security-dev at lists.jboss.org
Sent: Tuesday, May 13, 2014 12:00:54 PM
Subject: [security-dev] PicketLink Contribution from community volunteer: Max

Hi all,
   Max is a PicketLink community volunteer. He initially had a question 
about using custom user types in PicketLink IDM.

Pedro worked with Max to convert Max's use case into an excellent 
quickstart/demo. Thanks to Max for the contribution.

https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-angularjs-rest

The quickstart has the following features:

    - Secure HTML5-based applications using AngularJS at the frontend
    - Secure RESTful endpoints based on RBAC and Security Annotations
    - Token-based Authentication using JSON Web Token and JSON Web Signature
    - Provide a custom credential type and handler
    - Provide your own types to represent your users

Regards,
Anil
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev

From eric.wittmann at redhat.com  Tue May 20 11:28:28 2014
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 20 May 2014 11:28:28 -0400
Subject: [security-dev] Feedback: IDPFilter/SPFilter
Message-ID: <537B749C.2070803@redhat.com>

Hey everyone.  Recently we've switched Overlord over to using primarily 
the IDPFilter and SPFilter implementations for our picketlink based SAML 
SSO solution.  Previously we were using the app-server specific approach 
(e.g. valves).  We're doing this because we need to support both JBoss 
and Fuse.  The latter is an OSGi environment and uses Jetty as its web 
app container.  We also support standalone jetty (why not?) and Tomcat.

My hope was that I could have as few differences as possible with 
respect to security across all these platforms.  Hence the attempt to 
use the filter implementations where possible.

Overall this effort resulted in some success and some failure. 
Primarily, we have been successful in using the filter approach to get 
everything working in Fuse!  This was the primary goal, so that's great.

However, here are some issues we ran into (and are still problems):

1) I couldn't get our IDP working in JBoss EAP 6.x when using the 
IDPFilter approach.  The problem is that the IDP doesn't seem to do the 
redirect back to the SP.  I poked at this a *very* little bit but didn't 
find the problem.  Workaround:  continue to use the more native approach 
when deploying to EAP.

2) Ran into a pax-web bug that caused an infinite redirect loop when 
using welcome-files in the SP web.xml.  Workaround: implement a custom 
filter to mimic welcome-file behavior.  (this is not a problem with 
picketlink, just informational)

3) When running in jetty (or in fuse) we see a number of picketlink 
stack traces:  https://gist.github.com/EricWittmann/aafd2c05954cbfea8a87 
  Workaround:  none - we're ignoring them. :(

So finally, if you want to reproduce any of these or just have a look at 
some code, go here:

https://github.com/EricWittmann/karaf-picketlink-test

See the README.md for a description of how to run it either in Fuse or 
Jetty.  To run it in EAP just copy the relevant WARs into 
standalone/deployments (make sure to name them properly as I have not 
included jboss-web.xml files:  idp.war, sp1.war, sp2.war).

-Eric

From Anil.Saldhana at redhat.com  Tue May 20 15:39:21 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 20 May 2014 14:39:21 -0500
Subject: [security-dev] Feedback: IDPFilter/SPFilter
In-Reply-To: <537B749C.2070803@redhat.com>
References: <537B749C.2070803@redhat.com>
Message-ID: <537BAF69.5060600@redhat.com>

On 05/20/2014 10:28 AM, Eric Wittmann wrote:
> Hey everyone.  Recently we've switched Overlord over to using primarily
> the IDPFilter and SPFilter implementations for our picketlink based SAML
> SSO solution.  Previously we were using the app-server specific approach
> (e.g. valves).  We're doing this because we need to support both JBoss
> and Fuse.  The latter is an OSGi environment and uses Jetty as its web
> app container.  We also support standalone jetty (why not?) and Tomcat.
>
> My hope was that I could have as few differences as possible with
> respect to security across all these platforms.  Hence the attempt to
> use the filter implementations where possible.
>
> Overall this effort resulted in some success and some failure.
> Primarily, we have been successful in using the filter approach to get
> everything working in Fuse!  This was the primary goal, so that's great.
>
> However, here are some issues we ran into (and are still problems):
>
> 1) I couldn't get our IDP working in JBoss EAP 6.x when using the
> IDPFilter approach.  The problem is that the IDP doesn't seem to do the
> redirect back to the SP.  I poked at this a *very* little bit but didn't
> find the problem.  Workaround:  continue to use the more native approach
> when deploying to EAP.

It may be related to a bug in JBossWeb packaged as of EAP 6.2
where in the FORM Authenticator does not restore the post data
after authentication.

If you use a community module of JBossWeb that is more recent, you
will see that it works.

I have tried with jbossweb-7.4.0.Beta3.jar

http://repository.jboss.org/nexus/content/groups/public/org/jboss/web/jbossweb/

I would think 7.4.2.Final would have it too. :)

>
> 2) Ran into a pax-web bug that caused an infinite redirect loop when
> using welcome-files in the SP web.xml.  Workaround: implement a custom
> filter to mimic welcome-file behavior.  (this is not a problem with
> picketlink, just informational)
The SPFilter definitely needs additional testing and updates. If you want
to add in the welcome file behavior to SPFilter, please feel free to 
send a PR.
> 3) When running in jetty (or in fuse) we see a number of picketlink
> stack traces:  https://gist.github.com/EricWittmann/aafd2c05954cbfea8a87
>    Workaround:  none - we're ignoring them. :(
One end is complaining when the other end has closed. Hmmm... Wonder
why this is happening.

> So finally, if you want to reproduce any of these or just have a look at
> some code, go here:
>
> https://github.com/EricWittmann/karaf-picketlink-test
>
> See the README.md for a description of how to run it either in Fuse or
> Jetty.  To run it in EAP just copy the relevant WARs into
> standalone/deployments (make sure to name them properly as I have not
> included jboss-web.xml files:  idp.war, sp1.war, sp2.war).
>
> -Eric
>