-
1. PingFederate integration
anil.saldhana Feb 11, 2011 8:21 PM (in response to toddstory)Just use the service URL as assertion
consumer. Why can't the IDP just
send back the assertion to whoever
requested it, like the other IDPs.
-
2. PingFederate integration
toddstory Feb 14, 2011 10:05 AM (in response to anil.saldhana)That makes sense, especially from my past experiences. I was led to believe it was something else (i.e. a more specific URI). So, they should definitely just be POSTing to the service URL, correct?
-
3. PingFederate integration
anil.saldhana Feb 14, 2011 10:44 AM (in response to toddstory)There is no magic here. All IDPs display the behavior I just mentioned. When a PicketLink SP sends a request to the IDP, we do send the assertionconsumer url to be the service url. So on the SP side, configure the service-url property.
I do strongly request contributing a Ping interop document to the PicketLink wiki either by you or one of your team members. The PicketLink community will greatly benefit from it.
-
4. PingFederate integration
toddstory Feb 14, 2011 3:52 PM (in response to anil.saldhana)Agreed. I appreciate the information and I'd like to contribute to the wiki as soon as we get this completed. The initial PIcketLink was fairly painless to setup - I appreciate all the information contributed to this point. Thanks again and I'll update this discussion when the issues are resolved.
-
5. PingFederate integration
toddstory Feb 18, 2011 12:58 PM (in response to toddstory)Another item has come up. It looks like we'll have to digitally sign the SAML assertion. Is this what's in the user guide -- "Chapter 4. Web SSO - XML Signature Support"? Thanks.
-
-
7. PingFederate integration
toddstory Feb 21, 2011 12:57 PM (in response to anil.saldhana)The following is what is being returned by the IDP as the response. I obfuscated the specifics (IDP domain and the SP's IP and context) and removed the certificate data, but it's definitely POSTing back to my SP module. The service URL is indeed the 'gctxyz'. The post is immediately redirecting back to the IDP. Is there something wrong with the response or is there an additional step I'm missing. I've imported the certificate I was given, but configuration-wise I'm not 100% certain. Any ideas/comments are welcome.
<samlp:Response Destination="https://201.000.000.00/gctxyz" InResponseTo="ID_76b05a86-993e-4ba4-83b6-e0fe7d292e78"
IssueInstant="2011-02-21T17:35:08.182Z" ID="o5x7YnbyTo.XL_47-oLmZwgUgpP" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://test.xyz.com</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#o5x7YnbyTo.XL_47-oLmZwgUgpP">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>joOnzlFL1squOg8uAb5fLcA9x0s=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
...
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
...
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
...
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion Version="2.0" IssueInstant="2011-02-21T17:35:08.196Z" ID="RM9ViMLu.M-ejey1FVNCeeIBws."
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer>https://test.xyz.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">asptest</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="ID_76b05a86-993e-4ba4-83b6-e0fe7d292e78"
NotOnOrAfter="2011-02-21T17:40:08.196Z"
Recipient="https://201.000.000.00/gctxyz"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotOnOrAfter="2011-02-21T17:40:08.196Z" NotBefore="2011-02-21T17:30:08.196Z">
<saml:AudienceRestriction>
<saml:Audience>https://201.000.000.00/gctxyz</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2011-02-21T17:35:08.195Z" SessionIndex="RM9ViMLu.M-ejey1FVNCeeIBws.">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="street">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_street
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="zipcode">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_zipcode
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="state">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_state
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="lastname">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_lastname
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="firstname">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_firstname
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="billtoid">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_billtoid
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="telephonenumber">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_telephonenumber
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="city">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_city
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="email">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_email
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="contractnumber">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
asptest_contractnumber
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
-
8. PingFederate integration
anil.saldhana Feb 22, 2011 10:15 AM (in response to toddstory)Todd, that should work. Any specific exceptions you seeing?
-
9. PingFederate integration
toddstory Feb 22, 2011 3:03 PM (in response to anil.saldhana)No, I'm not seeing any specific exceptions. I've verified through HTTPFox that the POST is coming into my SP, but then it immediately redirects back to IdP.
The following is my picketlink-idfed.xml. Does this seem correct?
<PicketLinkSP xmlns="urn:picketlink:identity-federation:config:1.0" ServerEnvironment="tomcat">
<IdentityURL>https://fedtst.company.com/idp/SSO.saml2</IdentityURL>
<ServiceURL>https://201.000.000.00/gctxyz</ServiceURL>
<Trust>
<Domains>localhost,jboss.com,jboss.org,fedtst.company.com</Domains>
</Trust>
<KeyProvider
ClassName="org.picketlink.identity.federation.core.impl.KeyStoreKeyManager">
<Auth Key="KeyStoreURL" Value="/jbid_test_keystore.jks" />
<Auth Key="KeyStorePass" Value="store123" />
<Auth Key="SigningKeyPass" Value="test123" />
<Auth Key="SigningKeyAlias" Value="servercert" />
<ValidatingAlias Key="localhost" Value="picketlink"/>
<ValidatingAlias Key="127.0.0.1" Value="picketlink"/>
<ValidatingAlias Key="fedtst.company.com" Value="test"/>
</KeyProvider>
</PicketLinkSP>
-
10. PingFederate integration
anil.saldhana Feb 22, 2011 5:49 PM (in response to toddstory)Todd, let me run some local tests to see what the behavior is.
-
11. Re: PingFederate integration
anil.saldhana Feb 22, 2011 9:23 PM (in response to anil.saldhana)Todd. I did some local unit testing.
I see that we are assuming that the attribute statements will contain the roles from the IDP. That needs to be changed at our end.
JIRA: https://issues.jboss.org/browse/PLFED-140
Set of Roles:
======
[asptest_street, asptest_zipcode, asptest_state, asptest_lastname, asptest_firstname, asptest_billtoid, asptest_telephonenumber, asptest_city, asptest_email, asptest_contractnumber]
=======
That is what the SP is picking the roles to be.
On the service provider side, what are the roles that you are expecting the user to have? The user name is working out to be "asptest".
Additional JIRA that needs to be fixed: https://issues.jboss.org/browse/PLFED-141
UPDATE: I have resolved the two jiras above. I need the following answers:
- Are you running your SP on Tomcat or JBoss?
- What roles are needed by your SP application?
- Is there a public IDP available running Ping?
-
12. Re: PingFederate integration
toddstory Feb 23, 2011 8:12 AM (in response to anil.saldhana)Thanks, Anil. That's great.
The user, "asptest", is what I'm expecting.
1) We're running on JBoss 5.1, using PicketLink 1.0.4.
2) Currently we're not expecting any roles from the IDP. The attributes we're seeing in the response are supposed to be updated information that we can store in our system (SP).
3) It looks like my attempts to ping the IDP are timing out. Is there something specific I can ask the IDP system owners?
-
13. PingFederate integration
anil.saldhana Feb 23, 2011 9:40 AM (in response to toddstory)1)Change ServerEnvironment="tomcat" to "jboss"
2) Enable trace level logging for org.picketlink in conf/jboss-log4j.xml
3) I would suggest you try out the new PicketLink v2.0 builds rather than v1.0.4. I will give some extra information soon about this.
-
14. Re: PingFederate integration
toddstory Feb 23, 2011 10:13 AM (in response to anil.saldhana)Done - 1 & 2. I'd like to try 2.0 builds as soon as possible. Thanks very much.