From adamdong at vidder.com  Thu Aug  7 19:17:58 2014
From: adamdong at vidder.com (Adam Dong)
Date: Thu, 7 Aug 2014 23:17:58 +0000
Subject: [security-dev] About keeping SPFilter more up-to-date
Message-ID: <855de74421544667aae79fa3df0cd0d2@CY1PR0401MB0939.namprd04.prod.outlook.com>

Hi, guys,

The current SPFilter doesn't support

1.       signing AuthnRequest

2.       decrypting Assertion NameID (it seems to support validating assertion signature, but I didn't get that far yet)

3.       loading/understanding the standard IDP metadata file (example below).

Is my understanding above correct ?

The reason I'm using the filter and not the valve is because I have to support web containers other than JBoss.

If I need those three things, should I go ahead and code them myself (and after testing, I could contribute back to the community, with the permission of my company) ?
Or is there effort already under-way ?
Or better yet, these are already done and ready to be shared ?

Thanks for any feed back.

Adam Dong

---------------------------------------- example IDP metadata file --------------------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8" standalone="true"?>

-<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://idp.ssocircle.com">


-<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">


-<KeyDescriptor use="signing">


-<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">


-<ds:X509Data>

<ds:X509Certificate> MIICjDCCAXSgAwIBAgIFAJRvxcMwDQYJKoZIhvcNAQEEBQAwLjELMAkGA1UEBhMCREUxEjAQBgNV BAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTk1NzIxWhcNMTYwODE3MTk1NzIx WjBLMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2lyY2xlMQwwCgYDVQQLEwNpZHAxGjAYBgNV BAMTEWlkcC5zc29jaXJjbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbzDRkudC/ aC2gMqRVVaLdPJJEwpFB4o71fR5bnNd2ocnnNzJ/W9CoCargzKx+EJ4Nm3vWmX/IZRCFvrvy9C78 fP1cmt6Sa091K9luaMAyWn7oC8h/YBXH7rB42tdvWLY4Kl9VJy6UCclvasyrfKx+SR4KU6zCsM62 2Kvp5wW67QIDAQABoxgwFjAUBglghkgBhvhCAQEBAf8EBAMCBHAwDQYJKoZIhvcNAQEEBQADggEB AJ0heua7mFO3QszdGu1NblGaTDXtf6Txte0zpYIt+8YUcza2SaZXXvCLb9DvGxW1TJWaZpPGpHz5 tLXJbdYQn7xTAnL4yQOKN6uNqUA/aTVgyyUJkWZt2giwEsWUvG0UBMSPS1tp2pV2c6/olIcbdYU6 ZecUz6N24sSS7itEBC6nwCVBoHOL8u6MsfxMLDzJIPBI68UZjz3IMKTDUDv6U9DtYmXLc8iMVZBn cYJn9NgNi3ghl9fYPpHcc6QbXeDUjhdzXXUqG+hB6FabGqdTdkIZwoi4gNpyr3kacKRVWJssDgak eL2MoDNqJyQ0fXC6Ze3f79CKy/WjeU5FLwDZR0Q= </ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>


-<KeyDescriptor use="encryption">


-<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">


-<ds:X509Data>

<ds:X509Certificate> MIICjDCCAXSgAwIBAgIFAJRvxcMwDQYJKoZIhvcNAQEEBQAwLjELMAkGA1UEBhMCREUxEjAQBgNV BAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTk1NzIxWhcNMTYwODE3MTk1NzIx WjBLMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2lyY2xlMQwwCgYDVQQLEwNpZHAxGjAYBgNV BAMTEWlkcC5zc29jaXJjbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbzDRkudC/ aC2gMqRVVaLdPJJEwpFB4o71fR5bnNd2ocnnNzJ/W9CoCargzKx+EJ4Nm3vWmX/IZRCFvrvy9C78 fP1cmt6Sa091K9luaMAyWn7oC8h/YBXH7rB42tdvWLY4Kl9VJy6UCclvasyrfKx+SR4KU6zCsM62 2Kvp5wW67QIDAQABoxgwFjAUBglghkgBhvhCAQEBAf8EBAMCBHAwDQYJKoZIhvcNAQEEBQADggEB AJ0heua7mFO3QszdGu1NblGaTDXtf6Txte0zpYIt+8YUcza2SaZXXvCLb9DvGxW1TJWaZpPGpHz5 tLXJbdYQn7xTAnL4yQOKN6uNqUA/aTVgyyUJkWZt2giwEsWUvG0UBMSPS1tp2pV2c6/olIcbdYU6 ZecUz6N24sSS7itEBC6nwCVBoHOL8u6MsfxMLDzJIPBI68UZjz3IMKTDUDv6U9DtYmXLc8iMVZBn cYJn9NgNi3ghl9fYPpHcc6QbXeDUjhdzXXUqG+hB6FabGqdTdkIZwoi4gNpyr3kacKRVWJssDgak eL2MoDNqJyQ0fXC6Ze3f79CKy/WjeU5FLwDZR0Q= </ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>


-<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">

<xenc:KeySize xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">128</xenc:KeySize>

</EncryptionMethod>

</KeyDescriptor>

<ArtifactResolutionService Location="https://idp.ssocircle.com:443/sso/ArtifactResolver/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" isDefault="true" index="0"/>

<SingleLogoutService Location="https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/ssocircle"/>

<SingleLogoutService Location="https://idp.ssocircle.com:443/sso/IDPSloPost/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPSloPost/metaAlias/ssocircle"/>

<SingleLogoutService Location="https://idp.ssocircle.com:443/sso/IDPSloSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

<ManageNameIDService Location="https://idp.ssocircle.com:443/sso/IDPMniRedirect/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPMniRedirect/metaAlias/ssocircle"/>

<ManageNameIDService Location="https://idp.ssocircle.com:443/sso/IDPMniPOSTmetaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPMniPOST/metaAlias/ssocircle"/>

<ManageNameIDService Location="https://idp.ssocircle.com:443/sso/IDPMniSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>

<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>

<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>

<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</NameIDFormat>

<SingleSignOnService Location="https://idp.ssocircle.com:443/sso/SSORedirect/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>

<SingleSignOnService Location="https://idp.ssocircle.com:443/sso/SSOPOST/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>

<SingleSignOnService Location="https://idp.ssocircle.com:443/sso/SSOSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

<NameIDMappingService Location="https://idp.ssocircle.com:443/sso/NIMSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

</IDPSSODescriptor>

</EntityDescriptor>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140807/9e02943c/attachment.html 

From asaldhan at redhat.com  Thu Aug  7 20:42:47 2014
From: asaldhan at redhat.com (Anil Saldhana)
Date: Thu, 7 Aug 2014 20:42:47 -0400 (EDT)
Subject: [security-dev] About keeping SPFilter more up-to-date
In-Reply-To: <855de74421544667aae79fa3df0cd0d2@CY1PR0401MB0939.namprd04.prod.outlook.com>
References: <855de74421544667aae79fa3df0cd0d2@CY1PR0401MB0939.namprd04.prod.outlook.com>
Message-ID: <A436E109-F7AC-46BB-AB27-B87077542546@redhat.com>

Some time ago we did identify that we need to update the SPFilter. We have not got to it yet. We certainly value your contribution immensely.

If you want to contribute, just send in a PR in increments.

> On Aug 7, 2014, at 6:18 PM, Adam Dong <adamdong at vidder.com> wrote:
> 
> Hi, guys,
>  
> The current SPFilter doesn?t support
> 1.       signing AuthnRequest
> 2.       decrypting Assertion NameID (it seems to support validating assertion signature, but I didn?t get that far yet)
> 3.       loading/understanding the standard IDP metadata file (example below).
>  
> Is my understanding above correct ?
>  
> The reason I?m using the filter and not the valve is because I have to support web containers other than JBoss.
>  
> If I need those three things, should I go ahead and code them myself (and after testing, I could contribute back to the community, with the permission of my company) ?
> Or is there effort already under-way ?
> Or better yet, these are already done and ready to be shared ?
>  
> Thanks for any feed back.
>  
> Adam Dong
>  
> ---------------------------------------- example IDP metadata file --------------------------------------------------------------------------------
>  
> <?xml version="1.0" encoding="UTF-8" standalone="true"?>
>  
> -<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://idp.ssocircle.com">
>  
>  
> -<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">
>  
>  
> -<KeyDescriptor use="signing">
>  
>  
> -<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>  
>  
> -<ds:X509Data>
>  
> <ds:X509Certificate> MIICjDCCAXSgAwIBAgIFAJRvxcMwDQYJKoZIhvcNAQEEBQAwLjELMAkGA1UEBhMCREUxEjAQBgNV BAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTk1NzIxWhcNMTYwODE3MTk1NzIx WjBLMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2lyY2xlMQwwCgYDVQQLEwNpZHAxGjAYBgNV BAMTEWlkcC5zc29jaXJjbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbzDRkudC/ aC2gMqRVVaLdPJJEwpFB4o71fR5bnNd2ocnnNzJ/W9CoCargzKx+EJ4Nm3vWmX/IZRCFvrvy9C78 fP1cmt6Sa091K9luaMAyWn7oC8h/YBXH7rB42tdvWLY4Kl9VJy6UCclvasyrfKx+SR4KU6zCsM62 2Kvp5wW67QIDAQABoxgwFjAUBglghkgBhvhCAQEBAf8EBAMCBHAwDQYJKoZIhvcNAQEEBQADggEB AJ0heua7mFO3QszdGu1NblGaTDXtf6Txte0zpYIt+8YUcza2SaZXXvCLb9DvGxW1TJWaZpPGpHz5 tLXJbdYQn7xTAnL4yQOKN6uNqUA/aTVgyyUJkWZt2giwEsWUvG0UBMSPS1tp2pV2c6/olIcbdYU6 ZecUz6N24sSS7itEBC6nwCVBoHOL8u6MsfxMLDzJIPBI68UZjz3IMKTDUDv6U9DtYmXLc8iMVZBn cYJn9NgNi3ghl9fYPpHcc6QbXeDUjhdzXXUqG+hB6FabGqdTdkIZwoi4gNpyr3kacKRVWJssDgak eL2MoDNqJyQ0fXC6Ze3f79CKy/WjeU5FLwDZR0Q= </ds:X509Certificate>
>  
> </ds:X509Data>
>  
> </ds:KeyInfo>
>  
> </KeyDescriptor>
>  
>  
> -<KeyDescriptor use="encryption">
>  
>  
> -<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>  
>  
> -<ds:X509Data>
>  
> <ds:X509Certificate> MIICjDCCAXSgAwIBAgIFAJRvxcMwDQYJKoZIhvcNAQEEBQAwLjELMAkGA1UEBhMCREUxEjAQBgNV BAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTk1NzIxWhcNMTYwODE3MTk1NzIx WjBLMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2lyY2xlMQwwCgYDVQQLEwNpZHAxGjAYBgNV BAMTEWlkcC5zc29jaXJjbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbzDRkudC/ aC2gMqRVVaLdPJJEwpFB4o71fR5bnNd2ocnnNzJ/W9CoCargzKx+EJ4Nm3vWmX/IZRCFvrvy9C78 fP1cmt6Sa091K9luaMAyWn7oC8h/YBXH7rB42tdvWLY4Kl9VJy6UCclvasyrfKx+SR4KU6zCsM62 2Kvp5wW67QIDAQABoxgwFjAUBglghkgBhvhCAQEBAf8EBAMCBHAwDQYJKoZIhvcNAQEEBQADggEB AJ0heua7mFO3QszdGu1NblGaTDXtf6Txte0zpYIt+8YUcza2SaZXXvCLb9DvGxW1TJWaZpPGpHz5 tLXJbdYQn7xTAnL4yQOKN6uNqUA/aTVgyyUJkWZt2giwEsWUvG0UBMSPS1tp2pV2c6/olIcbdYU6 ZecUz6N24sSS7itEBC6nwCVBoHOL8u6MsfxMLDzJIPBI68UZjz3IMKTDUDv6U9DtYmXLc8iMVZBn cYJn9NgNi3ghl9fYPpHcc6QbXeDUjhdzXXUqG+hB6FabGqdTdkIZwoi4gNpyr3kacKRVWJssDgak eL2MoDNqJyQ0fXC6Ze3f79CKy/WjeU5FLwDZR0Q= </ds:X509Certificate>
>  
> </ds:X509Data>
>  
> </ds:KeyInfo>
>  
>  
> -<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
>  
> <xenc:KeySize xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">128</xenc:KeySize>
>  
> </EncryptionMethod>
>  
> </KeyDescriptor>
>  
> <ArtifactResolutionService Location="https://idp.ssocircle.com:443/sso/ArtifactResolver/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" isDefault="true" index="0"/>
>  
> <SingleLogoutService Location="https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/ssocircle"/>
>  
> <SingleLogoutService Location="https://idp.ssocircle.com:443/sso/IDPSloPost/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPSloPost/metaAlias/ssocircle"/>
>  
> <SingleLogoutService Location="https://idp.ssocircle.com:443/sso/IDPSloSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
>  
> <ManageNameIDService Location="https://idp.ssocircle.com:443/sso/IDPMniRedirect/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPMniRedirect/metaAlias/ssocircle"/>
>  
> <ManageNameIDService Location="https://idp.ssocircle.com:443/sso/IDPMniPOSTmetaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPMniPOST/metaAlias/ssocircle"/>
>  
> <ManageNameIDService Location="https://idp.ssocircle.com:443/sso/IDPMniSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
>  
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
>  
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
>  
> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
>  
> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
>  
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</NameIDFormat>
>  
> <SingleSignOnService Location="https://idp.ssocircle.com:443/sso/SSORedirect/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
>  
> <SingleSignOnService Location="https://idp.ssocircle.com:443/sso/SSOPOST/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
>  
> <SingleSignOnService Location="https://idp.ssocircle.com:443/sso/SSOSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
>  
> <NameIDMappingService Location="https://idp.ssocircle.com:443/sso/NIMSoap/metaAlias/ssocircle" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
>  
> </IDPSSODescriptor>
>  
> </EntityDescriptor>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140807/38db6d6a/attachment-0001.html 

From bentmann at sonatype.com  Fri Aug  8 09:30:41 2014
From: bentmann at sonatype.com (Benjamin Bentmann)
Date: Fri, 08 Aug 2014 15:30:41 +0200
Subject: [security-dev] PicketLink 2.7 and XXE
Message-ID: <53E4D101.8040207@sonatype.com>

Hi,

a couple days back [0], I noticed that PicketLink 2.7.0.Beta1 was 
released but seems to miss changes to its DocumentUtil to disable entity 
expansion as done for e.g. the 2.6.x branch.

I'm not sure whether my Github comment reached anybody so I figured I 
make another attempt via this channel to ensure the potential issue 
doesn't fall through the cracks.

Bye,


Benjamin


[0] 
https://github.com/picketlink/picketlink/commit/e81bf14ea6dbbc1570b79f44f1179ae61a353040#commitcomment-7238470

From asaldhan at redhat.com  Fri Aug  8 10:06:06 2014
From: asaldhan at redhat.com (Anil Saldhana)
Date: Fri, 8 Aug 2014 10:06:06 -0400 (EDT)
Subject: [security-dev] PicketLink 2.7 and XXE
In-Reply-To: <53E4D101.8040207@sonatype.com>
References: <53E4D101.8040207@sonatype.com>
Message-ID: <F696B9D2-C240-497A-AB00-A71C23B115B1@redhat.com>

Hi Benjamin - thanks a lot. We will ensure that the fix gets into trunk.

> On Aug 8, 2014, at 8:30 AM, Benjamin Bentmann <bentmann at sonatype.com> wrote:
> 
> Hi,
> 
> a couple days back [0], I noticed that PicketLink 2.7.0.Beta1 was 
> released but seems to miss changes to its DocumentUtil to disable entity 
> expansion as done for e.g. the 2.6.x branch.
> 
> I'm not sure whether my Github comment reached anybody so I figured I 
> make another attempt via this channel to ensure the potential issue 
> doesn't fall through the cracks.
> 
> Bye,
> 
> 
> Benjamin
> 
> 
> [0] 
> https://github.com/picketlink/picketlink/commit/e81bf14ea6dbbc1570b79f44f1179ae61a353040#commitcomment-7238470
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev


From psilva at redhat.com  Fri Aug  8 14:22:41 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 8 Aug 2014 14:22:41 -0400 (EDT)
Subject: [security-dev] PicketLink 2.7 and XXE
In-Reply-To: <F696B9D2-C240-497A-AB00-A71C23B115B1@redhat.com>
References: <53E4D101.8040207@sonatype.com>
	<F696B9D2-C240-497A-AB00-A71C23B115B1@redhat.com>
Message-ID: <1525647624.3907326.1407522161102.JavaMail.zimbra@redhat.com>

Hey All,

   I've merged Peter's commit into upstream/master.

Thanks Benjamin.

----- Original Message -----
From: "Anil Saldhana" <asaldhan at redhat.com>
To: "Benjamin Bentmann" <bentmann at sonatype.com>
Cc: security-dev at lists.jboss.org
Sent: Friday, August 8, 2014 11:06:06 AM
Subject: Re: [security-dev] PicketLink 2.7 and XXE

Hi Benjamin - thanks a lot. We will ensure that the fix gets into trunk.

> On Aug 8, 2014, at 8:30 AM, Benjamin Bentmann <bentmann at sonatype.com> wrote:
> 
> Hi,
> 
> a couple days back [0], I noticed that PicketLink 2.7.0.Beta1 was 
> released but seems to miss changes to its DocumentUtil to disable entity 
> expansion as done for e.g. the 2.6.x branch.
> 
> I'm not sure whether my Github comment reached anybody so I figured I 
> make another attempt via this channel to ensure the potential issue 
> doesn't fall through the cracks.
> 
> Bye,
> 
> 
> Benjamin
> 
> 
> [0] 
> https://github.com/picketlink/picketlink/commit/e81bf14ea6dbbc1570b79f44f1179ae61a353040#commitcomment-7238470
> _______________________________________________
> 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 adamdong at vidder.com  Fri Aug  8 18:07:30 2014
From: adamdong at vidder.com (Adam Dong)
Date: Fri, 8 Aug 2014 22:07:30 +0000
Subject: [security-dev] Does PicketLink SAML offering support xml decryption
	?
Message-ID: <1c3f4ca29ae14493b128d7c4b9cf63d9@BY2PR0401MB0934.namprd04.prod.outlook.com>

Specifically for decrypting <EncryptedID>, <EncryptedAssertion> or <EncryptedAttribute> on The SP side ?

Thanks,
Adam Dong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140808/130f14be/attachment.html 

From psilva at redhat.com  Fri Aug  8 18:24:22 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 8 Aug 2014 18:24:22 -0400 (EDT)
Subject: [security-dev] Does PicketLink SAML offering support xml
 decryption	?
In-Reply-To: <1c3f4ca29ae14493b128d7c4b9cf63d9@BY2PR0401MB0934.namprd04.prod.outlook.com>
References: <1c3f4ca29ae14493b128d7c4b9cf63d9@BY2PR0401MB0934.namprd04.prod.outlook.com>
Message-ID: <24936819.4024297.1407536662961.JavaMail.zimbra@redhat.com>

I'm pretty sure about EncryptedAssertion. We have quickstarts for that:

https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-federation-saml-idp-with-encryption
https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-federation-saml-sp-with-encryption

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Friday, August 8, 2014 7:07:30 PM
Subject: [security-dev] Does PicketLink SAML offering support xml decryption	?



Specifically for decrypting <EncryptedID>, <EncryptedAssertion> or <EncryptedAttribute> on The SP side ? 



Thanks, 

Adam Dong 

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

From adamdong at vidder.com  Fri Aug  8 18:45:15 2014
From: adamdong at vidder.com (Adam Dong)
Date: Fri, 8 Aug 2014 22:45:15 +0000
Subject: [security-dev] Does PicketLink SAML offering support xml
 decryption	?
In-Reply-To: <24936819.4024297.1407536662961.JavaMail.zimbra@redhat.com>
References: <1c3f4ca29ae14493b128d7c4b9cf63d9@BY2PR0401MB0934.namprd04.prod.outlook.com>
	<24936819.4024297.1407536662961.JavaMail.zimbra@redhat.com>
Message-ID: <321fabc12c4f4fc3bd48555988e80ae3@BY2PR0401MB0934.namprd04.prod.outlook.com>

Pedro,

Thanks for the quick response. That was very helpful.

I took a quick look at those examples:

The IDP side has SAML2EncryptionHander configured in the handlers chain, that is understandable.
But why doesn't SP side have something like SAML2DecryptionHandler ? Where is the decryption code ? Is it in ServiceProviderAuthenticator itself and not in a handler ?

(A less important question: so the library supports only <EncryptedAssertion>, and not <EncryptedID> or <EncryptedAttribute>, right ?)

Thanks,
Adam

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Friday, August 08, 2014 3:24 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Does PicketLink SAML offering support xml decryption ?

I'm pretty sure about EncryptedAssertion. We have quickstarts for that:

https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-federation-saml-idp-with-encryption
https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-federation-saml-sp-with-encryption

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Friday, August 8, 2014 7:07:30 PM
Subject: [security-dev] Does PicketLink SAML offering support xml decryption	?



Specifically for decrypting <EncryptedID>, <EncryptedAssertion> or <EncryptedAttribute> on The SP side ? 



Thanks, 

Adam Dong 

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


From psilva at redhat.com  Fri Aug  8 19:53:58 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 8 Aug 2014 19:53:58 -0400 (EDT)
Subject: [security-dev] Does PicketLink SAML offering support xml
 decryption	?
In-Reply-To: <321fabc12c4f4fc3bd48555988e80ae3@BY2PR0401MB0934.namprd04.prod.outlook.com>
References: <1c3f4ca29ae14493b128d7c4b9cf63d9@BY2PR0401MB0934.namprd04.prod.outlook.com>
	<24936819.4024297.1407536662961.JavaMail.zimbra@redhat.com>
	<321fabc12c4f4fc3bd48555988e80ae3@BY2PR0401MB0934.namprd04.prod.outlook.com>
Message-ID: <780923843.4045840.1407542038912.JavaMail.zimbra@redhat.com>

The decryption is done by the SAML2AuthenticationHandler itself. That is why you don't need a specific handler on the SP. 

The SAML2EncryptionHandler is only to be used at the IdP side.

And yes, I think only EncryptedAssertion is supported. What means you always encrypt the entire assertion.

Regards.

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Friday, August 8, 2014 7:45:15 PM
Subject: RE: [security-dev] Does PicketLink SAML offering support xml decryption	?

Pedro,

Thanks for the quick response. That was very helpful.

I took a quick look at those examples:

The IDP side has SAML2EncryptionHander configured in the handlers chain, that is understandable.
But why doesn't SP side have something like SAML2DecryptionHandler ? Where is the decryption code ? Is it in ServiceProviderAuthenticator itself and not in a handler ?

(A less important question: so the library supports only <EncryptedAssertion>, and not <EncryptedID> or <EncryptedAttribute>, right ?)

Thanks,
Adam

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Friday, August 08, 2014 3:24 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Does PicketLink SAML offering support xml decryption ?

I'm pretty sure about EncryptedAssertion. We have quickstarts for that:

https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-federation-saml-idp-with-encryption
https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-federation-saml-sp-with-encryption

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Friday, August 8, 2014 7:07:30 PM
Subject: [security-dev] Does PicketLink SAML offering support xml decryption	?



Specifically for decrypting <EncryptedID>, <EncryptedAssertion> or <EncryptedAttribute> on The SP side ? 



Thanks, 

Adam Dong 

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

From psilva at redhat.com  Tue Aug 26 09:52:00 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 26 Aug 2014 09:52:00 -0400 (EDT)
Subject: [security-dev] PicketLink 2.7.0.Beta1 Released
In-Reply-To: <1756401623.11727774.1409061074803.JavaMail.zimbra@redhat.com>
Message-ID: <2058311741.11728074.1409061120573.JavaMail.zimbra@redhat.com>

Hi All,

     PicketLink 2.7.0.Beta1 has been released. More details at http://picketlink.org/news/2014/08/25/Release-2/.     

Regards.
Pedro Igor

From mposolda at redhat.com  Tue Aug 26 10:26:22 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Aug 2014 16:26:22 +0200
Subject: [security-dev] PicketLink 2.7.0.Beta1 Released
In-Reply-To: <2058311741.11728074.1409061120573.JavaMail.zimbra@redhat.com>
References: <2058311741.11728074.1409061120573.JavaMail.zimbra@redhat.com>
Message-ID: <53FC990E.3080108@redhat.com>

Congrats and Thanks for the great collaboration with LDAP fixes!

Marek

On 26.8.2014 15:52, Pedro Igor Silva wrote:
> Hi All,
>
>       PicketLink 2.7.0.Beta1 has been released. More details at http://picketlink.org/news/2014/08/25/Release-2/.
>
> Regards.
> Pedro Igor


From stian at redhat.com  Tue Aug 26 10:33:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 26 Aug 2014 10:33:00 -0400 (EDT)
Subject: [security-dev] PicketLink 2.7.0.Beta1 Released
In-Reply-To: <2058311741.11728074.1409061120573.JavaMail.zimbra@redhat.com>
References: <2058311741.11728074.1409061120573.JavaMail.zimbra@redhat.com>
Message-ID: <643129556.38663758.1409063580618.JavaMail.zimbra@redhat.com>

Nice, congrats!

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "security-dev >> \"security-dev" <security-dev at lists.jboss.org>
> Cc: "Lincoln Baxter" <lbaxter at redhat.com>, "George Gastaldi" <ggastald at redhat.com>
> Sent: Tuesday, 26 August, 2014 3:52:00 PM
> Subject: [security-dev] PicketLink 2.7.0.Beta1 Released
> 
> Hi All,
> 
>      PicketLink 2.7.0.Beta1 has been released. More details at
>      http://picketlink.org/news/2014/08/25/Release-2/.
> 
> Regards.
> Pedro Igor
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
> 

From adamdong at vidder.com  Wed Aug 27 14:18:51 2014
From: adamdong at vidder.com (Adam Dong)
Date: Wed, 27 Aug 2014 18:18:51 +0000
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly
 instead of in Jboss ?
Message-ID: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>

Hi,

Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a  web app's META-INF/context.xml  like below (as opposed to adding it in jboss-web.xml on Jboss) ?

<Context>
  <Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/>
</Context>


I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in.

java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144)
        at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
        at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
        at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648)
        at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561)
        at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637)
        at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599)
        at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837)
        at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
        at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
        at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
        at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
        at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247)
        at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

I tried with Tomcat 6 and the valve didn't get pulled in the request path, just as if it were not there.

Any experience or idea ?

Thanks,
Adam Dong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140827/bfc25961/attachment.html 

From psilva at redhat.com  Wed Aug 27 16:11:12 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 27 Aug 2014 16:11:12 -0400 (EDT)
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat
 directly instead of in Jboss ?
In-Reply-To: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
References: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
Message-ID: <732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com>

Which jar are u using ? picketlink-tomcat7-X.jar ?



----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 3:18:51 PM
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?



Hi, 



Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app?s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? 



<Context> 

<Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/> 

</Context> 





I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. 



java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V 

at java.lang.ClassLoader.defineClass1(Native Method) 

at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

at java.net.URLClassLoader.access$100(URLClassLoader.java:71) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:361) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 

at java.security.AccessController.doPrivileged(Native Method) 

at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 

at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144) 

at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) 

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) 

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) 

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) 

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) 

at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637) 

at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599) 

at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) 

at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385) 

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) 

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) 

at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) 

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) 

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) 

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) 

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) 

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) 

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247) 

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898) 

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 

at java.util.concurrent.FutureTask.run(FutureTask.java:262) 

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 

at java.lang.Thread.run(Thread.java:745) 



I tried with Tomcat 6 and the valve didn?t get pulled in the request path, just as if it were not there. 



Any experience or idea ? 



Thanks, 

Adam Dong 

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


From adamdong at vidder.com  Wed Aug 27 17:29:59 2014
From: adamdong at vidder.com (Adam Dong)
Date: Wed, 27 Aug 2014 21:29:59 +0000
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat
 directly instead of in Jboss ?
In-Reply-To: <732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com>
References: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
	<732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com>
Message-ID: <28aae4ab6b8c4f1a8f6a5d6581ba79d1@CY1PR0401MB0939.namprd04.prod.outlook.com>


Pedro,

The following are the jar files I put under <Tomcat_home>/lib (I first put them under my web app's WEB-INF/lib directory but tomcat couldn't find them):

bcprov-jdk15on-151.jar               
jboss-logging-3.1.0.GA.jar           
jboss-security-spi-4.0.18.final.jar  
log4j-1.2.16.jar                     
picketlink-common-2.6.0.Final.jar
picketlink-config-2.6.0.Final.jar
picketlink-federation-2.6.0.Final.jar
picketlink-jbas7-2.6.0.Final.jar

Where do I get that jar file you mentioned ? All the picketlink related jar files I got are from picketlink-installer-2.6.0.Final.zip, and in there the jar file you mentioned is not present.

Thanks,
Adam Dong

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Wednesday, August 27, 2014 1:11 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

Which jar are u using ? picketlink-tomcat7-X.jar ?



----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 3:18:51 PM
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?



Hi, 



Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app?s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? 



<Context> 

<Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/> 

</Context> 





I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. 



java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V 

at java.lang.ClassLoader.defineClass1(Native Method) 

at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

at java.net.URLClassLoader.access$100(URLClassLoader.java:71) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:361) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 

at java.security.AccessController.doPrivileged(Native Method) 

at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 

at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144) 

at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) 

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) 

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) 

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) 

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) 

at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637) 

at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599) 

at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) 

at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385) 

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) 

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) 

at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) 

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) 

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) 

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) 

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) 

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) 

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247) 

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898) 

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 

at java.util.concurrent.FutureTask.run(FutureTask.java:262) 

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 

at java.lang.Thread.run(Thread.java:745) 



I tried with Tomcat 6 and the valve didn?t get pulled in the request path, just as if it were not there. 



Any experience or idea ? 



Thanks, 

Adam Dong 

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


From adamdong at vidder.com  Wed Aug 27 21:18:32 2014
From: adamdong at vidder.com (Adam Dong)
Date: Thu, 28 Aug 2014 01:18:32 +0000
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat
 directly instead of in Jboss ?
References: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
	<732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com> 
Message-ID: <415821d98f084fd18081403b3bcad1e5@BY2PR0401MB0934.namprd04.prod.outlook.com>


OK, I found picketlink-tomcat7-single-2.6.0.Final.jar on picketlink.org site, replaced picketlink-jbas7-2.6.0.Final.jar with it. Now I got 

java.lang.NoClassDefFoundError: org/picketlink/identity/federation/bindings/tomcat/sp/AbstractSPFormAuthenticator

And I checked, indeed AbstractSPFormAuthenticator is not in picketlink-tomcat7-single-2.6.0.Final.jar, but in picketlink-jbas7-2.6.0.Final.jar.

Is picketlink-tomcat7-single-2.6.0.Final.jar missing a few files ? 
Should I grab those missing file from jbas7 jar file and put them into tomcat7 jar file ? 
Would they be compatible ?



To check the compatibility, I found the following. ServiceProviderAuthenticator.class in picketlink-tomcat7-single-2.6.0.Final.jar:
  1667 Sun Jun 22 03:04:00 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderAuthenticator.class

The same class in picketlink-jbas7-2.6.0.Final.jar:
   978 Sun Jun 22 03:03:56 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderAuthenticator.class


They are different. Is that correct ? Can I trust the AbstractSPFormAuthenticator.class in jbas7 jar file to work with 
ServiceProviderAuthenticator.class in tomcat7 jar file ?

Thanks,
Adam Dong


-----Original Message-----
From: Adam Dong 
Sent: Wednesday, August 27, 2014 2:29 PM
To: 'Pedro Igor Silva'
Cc: security-dev at lists.jboss.org
Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?


Pedro,

The following are the jar files I put under <Tomcat_home>/lib (I first put them under my web app's WEB-INF/lib directory but tomcat couldn't find them):

bcprov-jdk15on-151.jar               
jboss-logging-3.1.0.GA.jar           
jboss-security-spi-4.0.18.final.jar  
log4j-1.2.16.jar                     
picketlink-common-2.6.0.Final.jar
picketlink-config-2.6.0.Final.jar
picketlink-federation-2.6.0.Final.jar
picketlink-jbas7-2.6.0.Final.jar

Where do I get that jar file you mentioned ? All the picketlink related jar files I got are from picketlink-installer-2.6.0.Final.zip, and in there the jar file you mentioned is not present.

Thanks,
Adam Dong

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Wednesday, August 27, 2014 1:11 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

Which jar are u using ? picketlink-tomcat7-X.jar ?



----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 3:18:51 PM
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?



Hi, 



Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app?s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? 



<Context> 

<Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/> 

</Context> 





I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. 



java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V 

at java.lang.ClassLoader.defineClass1(Native Method) 

at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

at java.net.URLClassLoader.access$100(URLClassLoader.java:71) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:361) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 

at java.security.AccessController.doPrivileged(Native Method) 

at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 

at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144) 

at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) 

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) 

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) 

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) 

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) 

at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637) 

at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599) 

at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) 

at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385) 

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) 

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) 

at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) 

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) 

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) 

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) 

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) 

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) 

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247) 

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898) 

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 

at java.util.concurrent.FutureTask.run(FutureTask.java:262) 

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 

at java.lang.Thread.run(Thread.java:745) 



I tried with Tomcat 6 and the valve didn?t get pulled in the request path, just as if it were not there. 



Any experience or idea ? 



Thanks, 

Adam Dong 

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


From psilva at redhat.com  Thu Aug 28 08:34:40 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 28 Aug 2014 08:34:40 -0400 (EDT)
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat
 directly instead of in Jboss ?
In-Reply-To: <28aae4ab6b8c4f1a8f6a5d6581ba79d1@CY1PR0401MB0939.namprd04.prod.outlook.com>
References: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
	<732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com>
	<28aae4ab6b8c4f1a8f6a5d6581ba79d1@CY1PR0401MB0939.namprd04.prod.outlook.com>
Message-ID: <2046297805.12930576.1409229280878.JavaMail.zimbra@redhat.com>

The picketlink-jbas7 is only for EAP. Each container has its own "binding" jar.

For Tomcat7, please try:

https://repository.jboss.org/nexus/index.html#nexus-search;quick~picketlink-tomcat7.

Regards.

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 6:29:59 PM
Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?


Pedro,

The following are the jar files I put under <Tomcat_home>/lib (I first put them under my web app's WEB-INF/lib directory but tomcat couldn't find them):

bcprov-jdk15on-151.jar               
jboss-logging-3.1.0.GA.jar           
jboss-security-spi-4.0.18.final.jar  
log4j-1.2.16.jar                     
picketlink-common-2.6.0.Final.jar
picketlink-config-2.6.0.Final.jar
picketlink-federation-2.6.0.Final.jar
picketlink-jbas7-2.6.0.Final.jar

Where do I get that jar file you mentioned ? All the picketlink related jar files I got are from picketlink-installer-2.6.0.Final.zip, and in there the jar file you mentioned is not present.

Thanks,
Adam Dong

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Wednesday, August 27, 2014 1:11 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

Which jar are u using ? picketlink-tomcat7-X.jar ?



----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 3:18:51 PM
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?



Hi, 



Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app?s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? 



<Context> 

<Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/> 

</Context> 





I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. 



java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V 

at java.lang.ClassLoader.defineClass1(Native Method) 

at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

at java.net.URLClassLoader.access$100(URLClassLoader.java:71) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:361) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 

at java.security.AccessController.doPrivileged(Native Method) 

at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 

at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144) 

at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) 

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) 

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) 

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) 

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) 

at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637) 

at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599) 

at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) 

at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385) 

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) 

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) 

at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) 

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) 

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) 

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) 

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) 

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) 

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247) 

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898) 

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 

at java.util.concurrent.FutureTask.run(FutureTask.java:262) 

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 

at java.lang.Thread.run(Thread.java:745) 



I tried with Tomcat 6 and the valve didn?t get pulled in the request path, just as if it were not there. 



Any experience or idea ? 



Thanks, 

Adam Dong 

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


From psilva at redhat.com  Fri Aug 29 08:37:09 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 29 Aug 2014 08:37:09 -0400 (EDT)
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat
 directly instead of in Jboss ?
In-Reply-To: <415821d98f084fd18081403b3bcad1e5@BY2PR0401MB0934.namprd04.prod.outlook.com>
References: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
	<732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com>
	<415821d98f084fd18081403b3bcad1e5@BY2PR0401MB0934.namprd04.prod.outlook.com>
Message-ID: <2050570752.13563095.1409315829957.JavaMail.zimbra@redhat.com>

Hi Adam,

  This is the right GAV:

     <dependency>
      <groupId>org.picketlink.distribution</groupId>
      <artifactId>picketlink-tomcat7</artifactId>
      <version>${picketlink.version}</version>
     </dependency>

  The picketlink-tomact7-single can not be used alone. Try to download from here:

     https://repository.jboss.org/nexus/content/groups/public/org/picketlink/distribution/picketlink-tomcat7/2.6.0.Final/picketlink-tomcat7-2.6.0.Final.jar

Regards.
Pedro Igor

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 10:18:32 PM
Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?


OK, I found picketlink-tomcat7-single-2.6.0.Final.jar on picketlink.org site, replaced picketlink-jbas7-2.6.0.Final.jar with it. Now I got 

java.lang.NoClassDefFoundError: org/picketlink/identity/federation/bindings/tomcat/sp/AbstractSPFormAuthenticator

And I checked, indeed AbstractSPFormAuthenticator is not in picketlink-tomcat7-single-2.6.0.Final.jar, but in picketlink-jbas7-2.6.0.Final.jar.

Is picketlink-tomcat7-single-2.6.0.Final.jar missing a few files ? 
Should I grab those missing file from jbas7 jar file and put them into tomcat7 jar file ? 
Would they be compatible ?



To check the compatibility, I found the following. ServiceProviderAuthenticator.class in picketlink-tomcat7-single-2.6.0.Final.jar:
  1667 Sun Jun 22 03:04:00 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderAuthenticator.class

The same class in picketlink-jbas7-2.6.0.Final.jar:
   978 Sun Jun 22 03:03:56 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderAuthenticator.class


They are different. Is that correct ? Can I trust the AbstractSPFormAuthenticator.class in jbas7 jar file to work with 
ServiceProviderAuthenticator.class in tomcat7 jar file ?

Thanks,
Adam Dong


-----Original Message-----
From: Adam Dong 
Sent: Wednesday, August 27, 2014 2:29 PM
To: 'Pedro Igor Silva'
Cc: security-dev at lists.jboss.org
Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?


Pedro,

The following are the jar files I put under <Tomcat_home>/lib (I first put them under my web app's WEB-INF/lib directory but tomcat couldn't find them):

bcprov-jdk15on-151.jar               
jboss-logging-3.1.0.GA.jar           
jboss-security-spi-4.0.18.final.jar  
log4j-1.2.16.jar                     
picketlink-common-2.6.0.Final.jar
picketlink-config-2.6.0.Final.jar
picketlink-federation-2.6.0.Final.jar
picketlink-jbas7-2.6.0.Final.jar

Where do I get that jar file you mentioned ? All the picketlink related jar files I got are from picketlink-installer-2.6.0.Final.zip, and in there the jar file you mentioned is not present.

Thanks,
Adam Dong

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Wednesday, August 27, 2014 1:11 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

Which jar are u using ? picketlink-tomcat7-X.jar ?



----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 3:18:51 PM
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?



Hi, 



Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app?s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? 



<Context> 

<Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/> 

</Context> 





I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. 



java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V 

at java.lang.ClassLoader.defineClass1(Native Method) 

at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

at java.net.URLClassLoader.access$100(URLClassLoader.java:71) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:361) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 

at java.security.AccessController.doPrivileged(Native Method) 

at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 

at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144) 

at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) 

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) 

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) 

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) 

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) 

at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637) 

at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599) 

at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) 

at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385) 

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) 

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) 

at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) 

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) 

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) 

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) 

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) 

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) 

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247) 

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898) 

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 

at java.util.concurrent.FutureTask.run(FutureTask.java:262) 

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 

at java.lang.Thread.run(Thread.java:745) 



I tried with Tomcat 6 and the valve didn?t get pulled in the request path, just as if it were not there. 



Any experience or idea ? 



Thanks, 

Adam Dong 

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


From adamdong at vidder.com  Fri Aug 29 18:01:16 2014
From: adamdong at vidder.com (Adam Dong)
Date: Fri, 29 Aug 2014 22:01:16 +0000
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat
 directly instead of in Jboss ?
In-Reply-To: <2050570752.13563095.1409315829957.JavaMail.zimbra@redhat.com>
References: <4353f8a8c91a4704a7e6b58671be22d8@CY1PR0401MB0939.namprd04.prod.outlook.com>
	<732618262.12677383.1409170272740.JavaMail.zimbra@redhat.com>
	<415821d98f084fd18081403b3bcad1e5@BY2PR0401MB0934.namprd04.prod.outlook.com>
	<2050570752.13563095.1409315829957.JavaMail.zimbra@redhat.com>
Message-ID: <ca5c1a313b724ac091a554cee5d55bd2@BY2PR0401MB0934.namprd04.prod.outlook.com>

Pedro Igor,

Thank you so much. I will try it out and report the result back to this email group.

Adam Dong

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Friday, August 29, 2014 5:37 AM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

Hi Adam,

  This is the right GAV:

     <dependency>
      <groupId>org.picketlink.distribution</groupId>
      <artifactId>picketlink-tomcat7</artifactId>
      <version>${picketlink.version}</version>
     </dependency>

  The picketlink-tomact7-single can not be used alone. Try to download from here:

     https://repository.jboss.org/nexus/content/groups/public/org/picketlink/distribution/picketlink-tomcat7/2.6.0.Final/picketlink-tomcat7-2.6.0.Final.jar

Regards.
Pedro Igor

----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 10:18:32 PM
Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?


OK, I found picketlink-tomcat7-single-2.6.0.Final.jar on picketlink.org site, replaced picketlink-jbas7-2.6.0.Final.jar with it. Now I got 

java.lang.NoClassDefFoundError: org/picketlink/identity/federation/bindings/tomcat/sp/AbstractSPFormAuthenticator

And I checked, indeed AbstractSPFormAuthenticator is not in picketlink-tomcat7-single-2.6.0.Final.jar, but in picketlink-jbas7-2.6.0.Final.jar.

Is picketlink-tomcat7-single-2.6.0.Final.jar missing a few files ? 
Should I grab those missing file from jbas7 jar file and put them into tomcat7 jar file ? 
Would they be compatible ?



To check the compatibility, I found the following. ServiceProviderAuthenticator.class in picketlink-tomcat7-single-2.6.0.Final.jar:
  1667 Sun Jun 22 03:04:00 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderAuthenticator.class

The same class in picketlink-jbas7-2.6.0.Final.jar:
   978 Sun Jun 22 03:03:56 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderAuthenticator.class


They are different. Is that correct ? Can I trust the AbstractSPFormAuthenticator.class in jbas7 jar file to work with ServiceProviderAuthenticator.class in tomcat7 jar file ?

Thanks,
Adam Dong


-----Original Message-----
From: Adam Dong
Sent: Wednesday, August 27, 2014 2:29 PM
To: 'Pedro Igor Silva'
Cc: security-dev at lists.jboss.org
Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?


Pedro,

The following are the jar files I put under <Tomcat_home>/lib (I first put them under my web app's WEB-INF/lib directory but tomcat couldn't find them):

bcprov-jdk15on-151.jar               
jboss-logging-3.1.0.GA.jar           
jboss-security-spi-4.0.18.final.jar  
log4j-1.2.16.jar                     
picketlink-common-2.6.0.Final.jar
picketlink-config-2.6.0.Final.jar
picketlink-federation-2.6.0.Final.jar
picketlink-jbas7-2.6.0.Final.jar

Where do I get that jar file you mentioned ? All the picketlink related jar files I got are from picketlink-installer-2.6.0.Final.zip, and in there the jar file you mentioned is not present.

Thanks,
Adam Dong

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Wednesday, August 27, 2014 1:11 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

Which jar are u using ? picketlink-tomcat7-X.jar ?



----- Original Message -----
From: "Adam Dong" <adamdong at vidder.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 27, 2014 3:18:51 PM
Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?



Hi, 



Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app?s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? 



<Context> 

<Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator"/> 

</Context> 





I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. 



java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator overrides final method start.()V 

at java.lang.ClassLoader.defineClass1(Native Method) 

at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 

at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) 

at java.net.URLClassLoader.access$100(URLClassLoader.java:71) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:361) 

at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 

at java.security.AccessController.doPrivileged(Native Method) 

at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 

at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 

at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:144) 

at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1288) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) 

at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) 

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) 

at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) 

at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) 

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) 

at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) 

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) 

at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:637) 

at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:599) 

at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) 

at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:385) 

at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) 

at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) 

at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) 

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) 

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) 

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) 

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) 

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) 

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247) 

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898) 

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 

at java.util.concurrent.FutureTask.run(FutureTask.java:262) 

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 

at java.lang.Thread.run(Thread.java:745) 



I tried with Tomcat 6 and the valve didn?t get pulled in the request path, just as if it were not there. 



Any experience or idea ? 



Thanks, 

Adam Dong 

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