IdP 3.0 Roadmap (Clustering)

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

IdP 3.0 Roadmap (Clustering)

Ina Müller
The Roadmap says: "Add a clustering solution similar to HA-Shib".
Will this supersede Terracotta in IdP 3.x?

Ina

Reply | Threaded
Open this post in threaded view
|

Re: IdP 3.0 Roadmap (Clustering)

lajoie
Administrator
Yes.

On 11/16/10 8:16 AM, Ina Müller wrote:
> The Roadmap says: "Add a clustering solution similar to HA-Shib".
> Will this supersede Terracotta in IdP 3.x?
>
> Ina
>
>

--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Reply | Threaded
Open this post in threaded view
|

Re: IdP 3.0 Roadmap (Clustering)

Ryan Suarez
On 10-11-16 08:23 AM, Chad La Joie wrote:
> Yes.
>
> On 11/16/10 8:16 AM, Ina Müller wrote:
>> The Roadmap says: "Add a clustering solution similar to HA-Shib".
>> Will this supersede Terracotta in IdP 3.x?

Can you provide a link to this roadmap?  What is the timing for IdP 3.x
release?
Reply | Threaded
Open this post in threaded view
|

Re: IdP 3.0 Roadmap (Clustering)

lajoie
Administrator
https://spaces.internet2.edu/display/SHIB2/ProjectPlanning

There is no release time yet as there is not yet any truly committed
funding (i.e., people still have to put ink to paper).  My best guess is
early 2012.

On 12/6/10 1:04 PM, Ryan Suarez wrote:

> On 10-11-16 08:23 AM, Chad La Joie wrote:
>> Yes.
>>
>> On 11/16/10 8:16 AM, Ina Müller wrote:
>>> The Roadmap says: "Add a clustering solution similar to HA-Shib".
>>> Will this supersede Terracotta in IdP 3.x?
>
> Can you provide a link to this roadmap? What is the timing for IdP 3.x
> release?
>

--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Reply | Threaded
Open this post in threaded view
|

I want to decode value of SAMLRequest

Takuya Matsuhira
In reply to this post by Ryan Suarez
Hello,
I am Takuya Matsuhira.

I have a question.

When user accesses SP, SP redirects user's access to IdP
like this.

https://idp.server/idp/profile/SAML2/Redirect/SSO?SAMLRequest=jZJRT8IwFI...W7bUKmk4WupHj3%0ARlWld2MD3EJCIkLTduX3t0k%2FAQ%3D%3D%0A&RelayState=cookie%3Abfae126a

I want to decode the value of SAMLRequest to see its format.
But I can't.

In one side, I can decode the the value of SAMLResponse this command.
#cat samlresponse.txt |nkf --url-input -mB

I think both request and response are simply encoded by base64.
So, because I can decode SAMLResponse, I also can decode SAMLRequest
same way.


Please give me some advice.

Regards,

--
+---------------------------------------+
Takuya MATSUHIRA
E-mail:[hidden email]
+---------------------------------------+

Reply | Threaded
Open this post in threaded view
|

RE: I want to decode value of SAMLRequest

Cantor, Scott E.
> I think both request and response are simply encoded by base64.

You're incorrect. That's a Redirect binding message, please refer to the standard for the technical details.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Takuya Matsuhira
Thank you for your answer.

But I think I can decode the value of SAMLRequest.

Is it wrong?

(2010/12/07 11:58), Cantor, Scott E. wrote:

>> I think both request and response are simply encoded by base64.
>
> You're incorrect. That's a Redirect binding message, please refer to the standard for the technical details.
>
> -- Scott
>
>
>
>
>


--
+---------------------------------------+
松平 拓也(Takuya MATSUHIRA)
情報部情報企画課教育研究システム係
(総合メディア基盤センター)
Tel:076-234-6926
Fax:076-234-6918
E-mail:[hidden email]
+---------------------------------------+

Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Brent Putman
In reply to this post by Takuya Matsuhira


On 12/6/10 9:53 PM, Takuya Matsuhira wrote:
> In one side, I can decode the the value of SAMLResponse this command.
> #cat samlresponse.txt |nkf --url-input -mB


No that doesn't work, as Scott said.  As he suggested, you should look
at the specs if you really want to know the technical details of the
binding.  There is however this online tool which handles this for you,
if all you care about is getting the message decoded:

https://rnd.feide.no/software/saml_2_0_debugger/

Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Takuya Matsuhira
In reply to this post by Takuya Matsuhira
Thank you for your answer.

But I think I can decode the value of SAMLRequest.

Is it wrong?

(2010/12/07 11:58), Cantor, Scott E. wrote:

>> I think both request and response are simply encoded by base64.
>
> You're incorrect. That's a Redirect binding message, please refer to the standard for the technical details.
>
> -- Scott
>
>
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Brent Putman
In reply to this post by Takuya Matsuhira


On 12/6/10 10:17 PM, Takuya Matsuhira wrote:
> Thank you for your answer.
>
> But I think I can decode the value of SAMLRequest.
>
>


You can, but the encoding of the SAMLRequest message is not usually the
same as the SAMLResponse.  The Shibboleth SP by default uses the HTTP
Redirect binding of SAML on SAMLRequest.  The SAMLResponse from the IdP
is usually via the HTTP Post binding of SAML.  The 2 formats may look
similar (base 64 encoding is involved), but they are in fact not the
same.  Simple Base64 decode of the response using POST will work, but
will not work for Redirect.  The online tool I earlier mentioned
supports both bindings, if I recall correctly.

--Brent

Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Takuya Matsuhira
In reply to this post by Brent Putman
Thank you for noticing this site.

I could decode the value of SAMLRequest.

Regards,

(2010/12/07 12:18), Brent Putman wrote:

>
>
> On 12/6/10 9:53 PM, Takuya Matsuhira wrote:
>> In one side, I can decode the the value of SAMLResponse this command.
>> #cat samlresponse.txt |nkf --url-input -mB
>
>
> No that doesn't work, as Scott said.  As he suggested, you should look
> at the specs if you really want to know the technical details of the
> binding.  There is however this online tool which handles this for you,
> if all you care about is getting the message decoded:
>
> https://rnd.feide.no/software/saml_2_0_debugger/
>
>
>
>


--
+---------------------------------------+
Takuya MATSUHIRA
E-mail:[hidden email]
+---------------------------------------+

Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Jason Rosenfeld
I have a question which feels similar, but I don't think is the same
as that being asked by Takuya.

I am running a Shibboleth SP and for debugging purposes am trying to
get at a plain-text version of the AttributeStatement we are passed by
an IDP as part of the SAMLResponse.  I have shibd logging turned up to
debug mode such that it prints out a decoded version of the
SAMLResponse, but with some IDPs there appears to be a further level
of encryption within the SAMLResponse.  Is there a way to decrypt this
so that I can actually see the full AttributeStatement we are passed.
With most IDPs this seems to happen automatically, but with some it
appears that there is an extra layer of encryption.  I have included
two examples below, the first of what I would like to be seeing when
the AttributeStatement gets fully decrypted and written to the shibd
log and the second of when it does not and I often have debugging
difficulties.

Is there a security reason why the Shibd logger can't or shouldn't
print out a fully decrypted response to our log files?  We obviously
have this information fully decrypted at some point, but evidently it
is after it gets written to the log.  If it is not possible to get a
fully decrypted version of the AttributeStatement, I would at least
like to know why.

An instance where this was causing us problems was when we were
setting up communications with a new IDP and they were passing us an
invalid affiliation value.  We were successfully mapping the
affiliation in our attribute-map, but then we were discarding it
because it did not meet our attribute policy.  So I could see in the
shibd log the following warning:
2010-11-26 10:44:37 WARN Shibboleth.AttributeFilter [7062]: removed
value at position (0) of attribute (primary-affiliation) from
(https://abc.blahl.edu/idp/shibboleth)
and I could see in the transaction log that we had successfully mapped
a primary-affiliation, but I couldn't actually ever view the value
that we were passed, to find out why it was getting rejected.

Thanks a lot.

Jason Rosenfeld
[hidden email]

----------------------------------------------------------------------------------------------------------------------------

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://www.zimride.com/Shibboleth.sso/SAML2/POST"
ID="_07834ec1e2cfac785aa26dfb63cdc329"
InResponseTo="_37f2eda96a75b59122a704643085ab3f"
IssueInstant="2010-12-06T22:34:42.112Z" Version="2.0">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://abc.blah.edu/idp/shibboleth</saml2: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="#_07834ec1e2cfac785aa26dfb63cdc329">
                <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#">
                        <ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds
saml2 saml2p xs"/>
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>GlghQVSrZ1RRuRDaFigDkz+kASk=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
FGkcXHER/UFv7OHftwCMlKx5TUkQEIZBL3LUef41JitoAcijODsieInLc4hjQeKsrsrsGAd0850o
L8NMgGOh6pQ0tppjcD1F4s+VTJMJ6xQUQLB3ZBx3JxmqUflA+7X2s6QHZ09qe2+XsR1DK39+xC2m
WBtCJ/PX0Fstzyn1wVceMQExaJQjJnRcYNuq/nBL8jm5c9/II6wrnJBVIbSJmzjUgvVpBnJ284/+
i0v5VIKealk5eTQNevGruW5TpOIVEZrgCELGqatSnQlO6HHtsh+bTdvZm0qfsiRFbTBLgSjmuCc5
qN7LfJEC5MKhNss/ulbD4xmlD7d4JMgbfUBdIA==
</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>

<ds:X509Certificate>MIIDSDCCAjCgAwIBAgIVAOZ8NfBem6sHcI7F39sYmD/JG4YDMA0GCSqGSIb3DQEBBQUAMCIxIDAe
BgNVBAMTF3NoaWJpZHAuY2l0LmNvcm5lbGwuZWR1MB4XDTA5MTEyMzE4NTI0NFoXDTI5MTEyMzE4
NTI0NFowIjEgMB4GA1UEAxMXc2hpYmlkcC5jaXQuY29ybmVsbC5lZHUwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCTURo990uuODo/5ju3GZThcT67K3RXW69jwlBwfn3png75Dhyw9Xa5
0RFv0EbdfrojH1P19LyfCjubfsm9Z7FYkVWSVdPSvQ0BXx7zQxdTpE9137qj740tMJr7Wi+iWdky
BQS/bCNhuLHeNQor6NXZoBgX8HvLy4sCUb/4v7vbp90HkmP3FzJRDevzgr6PVNqWwNqptZ0vQHSF
5D3iBNbxq3csfRGQQyVi729XuWMSqEjPhhkf1UjVcJ3/cG8tWbRKw+W+OIm71k+99kOgg7Ivygnd
zzaGDVhDFMyiGZ4njMzEJT67sEq0pMuuwLMlLE/86mSvuGwO2Qacb1ckzjodAgMBAAGjdTBzMFIG
A1UdEQRLMEmCF3NoaWJpZHAuY2l0LmNvcm5lbGwuZWR1hi5odHRwczovL3NoaWJpZHAuY2l0LmNv
cm5lbGwuZWR1L2lkcC9zaGliYm9sZXRoMB0GA1UdDgQWBBSQgitoP2/rJMDepS1sFgM35xw19zAN
BgkqhkiG9w0BAQUFAAOCAQEAaFrLOGqMsbX1YlseO+SM3JKfgfjBBL5TP86qqiCuq9a1J6B7Yv+X
YLmZBy04EfV0L7HjYX5aGIWLDtz9YAis4g3xTPWe1/bjdltUq5seRuksJjybprGI2oAv/ShPBOyr
kadectHzvu5K6CL7AxNTWCSXswtfdsuxcKo65tO5TRO1hWlr7Pq2F+Oj2hOvcwC0vOOjlYNe9yRE
9DjJAzv4rrZUg71R3IEKNjfOF80LYPAFD2Spp36uB6TmSYl1nBmS5LgWF4EpEuODPSmy4sIV6jl1
otuyI/An2dOcNqcgu7tYEXLXC8N6DXggDWPtPRdpk96UW45huvXudpZenrcd7A==</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </saml2p:Status>
    <saml2:Assertion
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_5136c72de7596fcd950c46ca507fd990"
IssueInstant="2010-12-06T22:34:42.112Z" Version="2.0">
        <saml2:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://abc.blah.edu/idp/shibboleth</saml2:Issuer>
        <saml2:Subject>
            <saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_893a78f3524283f00f5dc2a1a3d3e17c</saml2:NameID>
            <saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml2:SubjectConfirmationData
Address="128.84.152.209"
InResponseTo="_37f2eda96a75b59122a704643085ab3f"
NotOnOrAfter="2010-12-06T22:39:42.112Z"
Recipient="https://www.zimride.com/Shibboleth.sso/SAML2/POST"/>
            </saml2:SubjectConfirmation>
        </saml2:Subject>
        <saml2:Conditions NotBefore="2010-12-06T22:34:42.112Z"
NotOnOrAfter="2010-12-06T22:39:42.112Z">
            <saml2:AudienceRestriction>

<saml2:Audience>https://www.zimride.com/shibboleth</saml2:Audience>
            </saml2:AudienceRestriction>
        </saml2:Conditions>
        <saml2:AuthnStatement AuthnInstant="2010-12-06T22:34:42.090Z"
SessionIndex="1c4678d15e43a3fadef98a9aedde801088042e99f77cf0c6bb32bed0ed1bd34d">
            <saml2:SubjectLocality Address="128.84.152.209"/>
            <saml2:AuthnContext>

<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
            </saml2:AuthnContext>
        </saml2:AuthnStatement>
        <saml2:AttributeStatement>
            <saml2:Attribute
FriendlyName="edupersonprimaryaffiliation"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">student</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="eduPersonPrincipalName"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">[hidden email]</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="givenName"
Name="urn:oid:2.5.4.42"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ABC</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="uid"
Name="urn:oid:0.9.2342.19200300.100.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ABC</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="mail"
Name="urn:oid:0.9.2342.19200300.100.1.3"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">[hidden email]</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ABC</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="eduPersonAffiliation"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">student</saml2:AttributeValue>
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">member</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute FriendlyName="displayName"
Name="urn:oid:2.16.840.1.113730.3.1.241"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml2:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ABCDEFG</saml2:AttributeValue>
            </saml2:Attribute>
        </saml2:AttributeStatement>
    </saml2:Assertion>
</saml2p:Response>

---------------------------------------------------------------------------------------------------------------------------------------------

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://www.zimride.com/Shibboleth.sso/SAML2/POST"
ID="_7780159166171e901a788bbf3faee262"
InResponseTo="_68251c9389a1aa77d615bd6b3d71a389"
IssueInstant="2010-12-07T03:09:56.873Z" Version="2.0">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">urn:mace:incommon:xyz.edu</saml2: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="#_7780159166171e901a788bbf3faee262">
                <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#">
                        <ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds
saml2 saml2p xenc"/>
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>W2QciKaJI+811eGM3q36m12ZMC8=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
ouD6QNPqR7+qTwujNsVXUqsyNdUGZKq6JYGK/NalosxvapaCfg5uA+fj4Qr57c3MSXPbq0fUc0qv
6qGViq022p7tXOBY5l5tOgl0WbhiB+oSzET4P2VLKrdqS80xA1kzt3/972FRJ8c3KFbj6RKlCEAb
TkvhnqU+qfTpka+NDbpyTKoSr09wBxVXtzsVnZxD1uZIdm15N6pT2I2BiJbztV8yMevM2hezt0Gy
eE4mGSDrkgCsXoJBF3mFNC1rt6TK2LcuapNTX0+IskaO2FgBKO7zaD165mwZNoAoB2ug4IXtki2a
XW0dRwGN33WyPnQgq9rSfxOKLARS+cy27l0Hvw==
</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>

<ds:X509Certificate>MIIFizCCBHOgAwIBAgICAeQwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxHDAaBgNVBAoT
E0luQ29tbW9uIEZlZGVyYXRpb24xKTAnBgNVBAMTIEluQ29tbW9uIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTA5MDExNTIwMTUxOVoXDTExMDExNjIwMTUxOVowGDEWMBQGA1UEAxMNc2hpYi5u
Y3N1LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTnJzLSRt2QQkY5unH3Y1zd
2fVXIJts+Pc++MW9dKq9/Fba3yP3i+SI5ldeO8+PU/vBl263MMkli8yZArbh7dIuLBzuNTRbHBmi
8How6HAQYqWa/J4mv7gi111k7e0yxjVagfj0PyKP72JVQ5prDVGYi/YlBaic5mVtdRtaWUgoudmA
cpN10cqkX018UF9LVas8HAVQMWKKzxmix9ICAIilVrep0qXJdfLKJ4QrHXY6jVWrhcco+nKx44gg
Es2cOFs6ej+LCRGq2WBYicAcOPEkYzAgcJXoBoSgyQzhxPMbypWTupI7uxRlSM3j0N44skhF/HyZ
CujcvCk59qbdEFECAwEAAaOCAp8wggKbMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUd0bT0fZn8kzZVApw511MXYuf
5kkwfgYDVR0jBHcwdYAUky3IYRitY+ObZbOd3Y2TuufKY0WhWqRYMFYxCzAJBgNVBAYTAlVTMRww
GgYDVQQKExNJbkNvbW1vbiBGZWRlcmF0aW9uMSkwJwYDVQQDEyBJbkNvbW1vbiBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIBADCBsgYIKwYBBQUHAQEEgaUwgaIwTwYIKwYBBQUHMAKGQ2h0dHA6Ly9p
bmNvbW1vbmNhMS5pbmNvbW1vbmZlZGVyYXRpb24ub3JnL2JyaWRnZS9jZXJ0cy9jYS1jZXJ0cy5w
N2IwTwYIKwYBBQUHMAKGQ2h0dHA6Ly9pbmNvbW1vbmNhMi5pbmNvbW1vbmZlZGVyYXRpb24ub3Jn
L2JyaWRnZS9jZXJ0cy9jYS1jZXJ0cy5wN2IwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0cDovL2lu
Y29tbW9uY3JsMS5pbmNvbW1vbmZlZGVyYXRpb24ub3JnL2NybC9lZWNybHMuY3JsMD+gPaA7hjlo
dHRwOi8vaW5jb21tb25jcmwyLmluY29tbW9uZmVkZXJhdGlvbi5vcmcvY3JsL2VlY3Jscy5jcmww
XgYDVR0gBFcwVTBTBgsrBgEEAa4jAQQBATBEMEIGCCsGAQUFBwIBFjZodHRwOi8vaW5jb21tb25j
YS5pbmNvbW1vbmZlZGVyYXRpb24ub3JnL3ByYWN0aWNlcy5wZGYwGAYDVR0RBBEwD4INc2hpYi5u
Y3N1LmVkdTANBgkqhkiG9w0BAQUFAAOCAQEATElENKovoVxVQCoqGGxpsFjUsGMpsJ8ULW2giOft
j4kAQqHhVumwzwSGoRzBAKlQ0Q7uBL8RZKhFgTbswYm6o7hNNlOrSXLTB9bGkUz+jgpqJaW7IImQ
mHlo0/Yh7eUD0DiAkR4QV15LG8xsck6x0wGL2OAdijAioMiwlQWLYeNRMV9Kav/8CbtEF2NGdEEf
Nlfo6LfMSfNw+HqijfpXBhSZK3QNO2QTDWwv3+/aaEBhLhL+R1JUcV9w4jJZ7/W/s1EDuHWA8PCD
N4/qPAyFPUeG/2sJEP71LdyZ0/oyb78x4cgsQim3WAL+C0b61QXcAtXaZ7agxbVSzRZUh+eZBA==</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </saml2p:Status>
    <saml2:EncryptedAssertion
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        <xenc:EncryptedData
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="_a493d569fc81c74611085bb44527d1a5"
Type="http://www.w3.org/2001/04/xmlenc#Element">
            <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <xenc:EncryptedKey
Id="_95a754d127eebeee75e2246d2ad72cdb"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                    <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                        <ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                    </xenc:EncryptionMethod>
                    <ds:KeyInfo>
                        <ds:X509Data>

<ds:X509Certificate>MIIDMjCCAhqgAwIBAgIJALHS3L4r3O8gMA0GCSqGSIb3DQEBBQUAMBoxGDAWBgNVBAMTD3d3dy56
aW1yaWRlLmNvbTAeFw0wOTEyMjMyMTA0MDdaFw0xMjEyMjIyMTA0MDdaMBoxGDAWBgNVBAMTD3d3
dy56aW1yaWRlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALekemUM1SMHdb8S
6D/t4UOb1zOEPTdIBlalJt54soWyKomuW4Pj/MqtXu5TiW0EBgXhLK2hvAF5OTMgi2DmegX8rbX4
Jz++D+1eYU7F12gj3GE0N7Tyi3MUTVknN5T0VlCe76y5xGPbzuyiQLYT+GzD72Sdwv3CUxEKR2ZN
VZbx7fITgfmR0kNDtqBfwNQLFAX3bi+3blqh0wnPb2CO5YizQ2t966GtePWBHlh2CjrIrD2k5l+H
3YpL3LM4w6T2FKDXU56rAgAn+iMdWTD5A7roy9n1cSjb9llcZhFCtIJ6xdlR729baxZ5qlyalMOL
Fpb/qtsYqbyeelpAbo3klhECAwEAAaN7MHkwHQYDVR0OBBYEFHaFq6OjhJ20qwXkS7ZWkZW+Jlbn
MEoGA1UdIwRDMEGAFHaFq6OjhJ20qwXkS7ZWkZW+JlbnoR6kHDAaMRgwFgYDVQQDEw93d3cuemlt
cmlkZS5jb22CCQCx0ty+K9zvIDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQAL8NIM
BPZgqFOFsR/m+c175/IetIKKcLtYxVh3ux6Op4uXmV1nCg1+/zdh6HXZQFALSIw/MIAI1vKYdv7P
sIPZUh7uJIJoJBsxkLLpEpBmJMNxPuJOYfyX+EfIF5r1h7WBzI02XT552hfhKorYUVwk4cxSSCyQ
OUgMlbCwFpmrm3pf2nV+EtfXSNK8qzJHYkf7RXqTyUFIcFn18puMz4r4BCddIfpSop9+bImir0wa
OEJt5SFBIKDhkBIroCK0blEGDnpNC4Uh9SfHg+AK//pH5g02ng5dUQQOYETY75O3yMo5LoMHcsBg
VxqENAXJKh5u2LvlvqApUIWE4rZ5DpaO</ds:X509Certificate>
                        </ds:X509Data>
                    </ds:KeyInfo>
                    <xenc:CipherData
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<xenc:CipherValue>Ilr87LKGq0Ko83z4OYYmgT//GbpjyPHlQLg5LvczckJ/o6VKWsS3mIia+0F5tT6EpVjc0s3AO0GR
PdZ43tfctuj9l+O5BfT/pDV1+4PiUsqCA5htspWKlAkGHQibgw+apUYsAajOLHjoiaPC4nLxSGb9
Pr78C6cLeSrPgnKCqA/uVRbAhcZSnTBbAwohbbwM1LMQZrnM//zv4JeSro+Q/vRnII7hA7GcgFRF
KZxZR8ND6ilJUkA8eA5RcJNhAucsh2y/OEX+kzOIOz9A9fpcb0aSLaVYBdqgobSIwgN724+5cZdS
ICe/n8kAug0b1AXwGRawO2mBIgfqoeDg0L6I4w==</xenc:CipherValue>
                    </xenc:CipherData>
                </xenc:EncryptedKey>
            </ds:KeyInfo>
            <xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<xenc:CipherValue>xeizaHixPXGJf3qwkX6iOFcq+gbkFA6KG8R8ZmUrWV5uMaBBmIMH/4iVyPUyK4wToyW2HvuWLqVX
nJZAP8LKiMG9jXjtqv++gW92y9WQk+v18oxeNic+Vcn0fBdUyop+sRgBF6A2ET9QKYLYklV8cuDr
d3ZesujRKxneTXd6mXPqGn0nASohe3GKdh0xaEMXfMjLR25B+YkMcNmU0exqpBYxmN5zzbY9gsVa
5E/pO2iTIZuwGTKZ2Un9CNbjbTFaOuXM6MGsWK8WzK2eHKwlUO9zN4gCzsfJvN7cRcBLWooQM8l7
iuRwwAXm3gJ+UlFTCZh+KXuOFjqqTpKicsl0w8sHjsH/JNyxyYoiWfRsrO0w9ZCiCT9Ojl7FMG3N
4k1JNNHIB6p/CkDz2wclAoXUPi73aZYdMGyxao7wxLS/xaTl70IZuBteqsUM798piB70UV/Kwd5W
rL6pH804ilSQ+aGoJ7FqEZAEywLIRwu+C02mQv5FRHYFi+eFuuwZK2fQiOz7zJHbp8mLH9kCQJgW
TSe5S9GQUaFj/CnoJh8uhFcWyoTmwbkjJaPkEMgg9cA00Ib/okzZ7tKYlWutNS2mSVRLzTf7MmM5
MCIOXtt7n4PftZiNJBsL+1QZmV9cUvtWwpjcLzuC3HSErGXXr4INllioeoLSg0Ds8oNA89ATTaEk
DWER5DSQrtstSFWZVp2NadAyNUFz5AQxCEvkd2KntIdZmEMpQd4NGxVr3SAtMwOw3J3CMoHFDRcR
/FXYiP8MEahb3N5+NGeoKtWgkf3vVDejhR8kWUQOVumIpxA3ffCM3wFFitGpDERpGU2YJcEQxuNh
pDZXkFRb+6OtX4lZyOVw6HGGGAV0SQhx3SukiWguTGVYgvQJoQ9+iAvmF+OTNs9jQtblfwsRFiJP
ThEBkHuIvmofSkETZ37x/H/2PrIDpuSzQcvVkEApl3Qbq/xDZtrfa7TOeO45Qhb4axLRShKG/ZVg
Y5X7PkE0wm9FdNIRierfSGtUcdJZFV9lH8tdYJBFEGhSafAcyrmviy19J1b79VRhQ0paOCsyH6bX
DwmED8MvPApvQCYeQYQc8Rr+hHUvDhmk+MgPFeyrfxknf8EBOyEbz0Nui7wtiSP1JP+yJB5F/SCq
EIiAJopMw5p4ORgSGK1NyTRySmakJkGXrv0dqdyR0lZVjvyJFftwTsVtlKlg1yYGAkVLYC8rRNwQ
93Ciw3NJQBHwfgWCanXfagmaZC3IFv2R7yrTiWc4gbc1SHPvPF+ccPwXNGUBOnTyyLvG1cJUDiL/
iRIkTVgN71bRBuCLS8BXjHv+17sTkCJ+/GJFlOD8umgmUR4w8QNjuAf9TH9fSBhSYPz5CIOAjKmn
oYkxVtRq7u/IxH7PMWejzW3nWLD2AicEzh9iQBHXgkPyQtXelU7PBjRRrAiI63PqO/37aQbBl91w
ISHZYuwwY72jSNyFpfDxID10N21EH5CitCheU+iTa1V8CUyAA6EtEtblYq+khevyz3jViVhpCZX7
W7UFJCVGJpk+54tG0Stzmb9bgPJ6QeSbFoi/1+NyyCO2vs3OAtBC1uOReIq+6J+4DZCj+hnN5SYD
bH1q5EOUnCT5pdvGXZ9pbBD4JssLCf8XY64kyOgJXCw+JyXK7Q/ad3/TcTmdX5aiT2v0+epRDBXF
q4VYzaOpj56cMTNPuUx9o5eZ9wEAivdPVpF4Auf93VC75HZoAUquxjZ3UxgWpvKeiwJVM4dOQ74N
Ln7dCMLKOXbdYqPn5XECMfONWLJ1ikuf+agVN4ZBuy4UP6V6SvDhTDi5ylOPIHH6HZX/W7bTmjN9
EjuD5V4Pl1IVa/IvI8eYv/kGdq8BZ0JbNkkMCs74WJWXEbnLIBx7wc7BLDE7q+63fqULjCEeHeO4
YNXpRLsC08hU/t0xGtP4DM+c5eQDdqQC4KaXvS5dO2/hPdOokjPIzjPAlYR+QMXPN0thHPWmEt0i
aO9DNqd65GwP+jP1GH3HI95ZrnvboDT/81jqtE5S7l1mLvx90ulHk8YRgr4CstTrkiqtFXM9olFv
XnjcmqpbvTcw+N3Id7IuC3Y+POVf79oYSWBzoJk5WJSTI9b+Emt7R7cg1WcwPAObpdLuotiPM6DF
5k5xNYHpltOzQvLAvEhRGI266YuClaJ0Fx8WShYjc0g/WZd9IFpe6xutVHXReOpGAfW9ID71DCV+
ve58TP02F9I9hg1Kuj/IxHLPK0k786rn/1KcAPuTVB9uC8lYQQ2wgnxjgtwqEgKZWhIDFHUwzraK
l8S5NYvQmmvhSJU/m6ASE15yHPKXa7l6E1GCX1ZpAiPnkwkBiH3ALO5hJOZhj2pkcyiU0pUEF+fA
IxJc2FC+ZXX0YuTZiAPlc21bDRA4Q1WIQ2vuaLNH28qtKTRu/91OodrWHNCVOCQ9/v1miYSKq36P
WZJ0KeagRmur4/L4FoduxbI2vKtpqmiav4qwm0HKcWpLZ0Z18K2+0njG5vl3Of1EU8cxNnZOathI
iBefhtPgAs/+NNQLqAcE66WCyAfbeo+JMgrJM8QpLtwDOhepHktHO3HFxruoZeUQlVVpJOrgLU/K
WBo9iX2SIkCBpMHvF8pMUB9ksuAYDU/grFiXoE/td4LFgnPg06+gJyRpiUxkiqRORZ2mDHjTHzV+
EgUez/A64XQuhfne1I3tfzDVqLhrxRlTkQOcKitjj5yBYCzvb3qagcsURi+1VfltM21GQ1asmVAd
4Q3kafAbpN3DH1spAbK3BfhG+BSOn4IUUr5g/fwiBpyodb2E5FuXcrUWZ5Gy0cOosfZ/VXKVhEWa
bvjWYWO+NOnSbZ5xo+WUyMLUZkJW2tJN8TDzX0CbwU5a0yE4Fek5z6eY3aDb+VTl1xLNsU6VrCZi
Ba1iOphtabXVAuW+gm3GflJSAs3Ai+zwaO9m1wJ9b6cD3YUudoXc71fnD1xKTYZL4Bvcm2Ly26O4
TR4MYunzHpINpxLnLUpil137yXwt0Pn5fKXzVE8OpfKipD291LeE1j7Fhj64SjObZt57togA7Jms
Hrfct8R+kaeN4uj9b+P4PUQs7l+1k5Cju0FCsue7V3DJ6VCiXeJRq0GvlBg1rcDOfsXvSOCljzAK
09ArRMF0WQNy1eFMhGLTmA+uQyHqgQ0QxlD5if/Cv8kewU4n0njGQJvDIiMEGZVuZ+r8yil2eyt2
vUnpn2pGbdkeCKKGYqCdDROJFIDXPDHeKCWF7smyDhlJjwLM83Q29W9yRbQ72+3eGp7voi9oa6E5
CxJUBduWwbyuz8BqmNuar1TijK25LcCSoeaqAta0Go4cwiYykKHP+4FPkSDA7cpRLajEeizstaDD
I7J8TfLObFpD7gpYqyu42iWHxhjmqhoklNvMH863f/Bao5nkNanFPkV9gOWPG11iYkQXa//d+dyN
KTkfj/RNKgu+ibc+dYVytDlosjV6YFUXEY806l46j+J9r4WGHJJZsULojuNpLHjpqOZ7BRiAczKF
C7XyXotKjGA6Gzqbf9xLwDdpUHHLQA8rSUn+TGUsg3Y2dyJUpY7St2QZSLGunIvWETR7CyKVQal2
8A8qnK6byXfP1edXJ3HSj1caJwM/CUeSKfJA3vOKjlaW6nRY/wia9XNwTPVMGq+eF66p0H8HJiqh
vfgD0wEIu1hdXHhCeWU24uZb/oat4Ne+mz9GwBJqvgjDKNMcl7xe0EWJc/CbkKM+gBFUGeWXamk4
00qdu1OGU3XsUxL8YdUnWdtCz1Cp5cUv/hQf1g5dGmmllLxEzsvkajHao9SdQoOdgjn2ACckW2wB
mm4v3Dbb9W+vv4Qdund8pLQNAqh4fPMN5x9OlmvSKk0D1Y8NRxvUkzy+lymVMec4ka5kSQI3piro
U/BY8xYEkUgtX6hc7G7EYOaA1b4E9YbzvqpVzPQC2tfnJI8XxheQjAIxtyWuVVcHJS005vCVFPN4
jxRU4mtjO/Fz+zmH61C/Rqn/YCiPRhsboE8NOS0v/+FK1/sIvXUcFk4USU7iVno40MxLrVOAqIzX
0m8jau1aekC+9jF5gQ1IB7hNB/EVVNTrLw9LRSmQrHVfOzvwc/V6YWhk5T21vY6nEihKyvMjy+IT
k7KGN2jXz933WhuBjnoQHdbtnjzvcjMJvL1O47MXc5WKRgUiDsEfHvHKpZ2eeXDFWdsapxsJhmdV
9UicdSo6AQzOfWpLQaELFUsEhjfwEyK3yL/U5E3/6eS6wzrhLxoQ2httaBMjAJENWJ4b6Bf5Wbke
I9kPIb/hBTk6MTCDj36+vUyg2T40WBJ+SnxTOsmLBgcoAQWGAZXl4e27ilEquCAv6rLdsiu6h2Du
QII6APXygs2HSGP9UqJrzVmaN1VDqSzcQFqrpROv39iHZ5vPuNTfFO1pYt5TsJRXhn/t8KxWk6wN
RuHZcYyIYPOd+So+3+Z29UVV6S4IZ5Aj9fUKE8rUMaMawUaRqZ/2XJlLQuqfwhYiqVyDAZzSDiAp
PVh0ZkdgWjTffGDl8DUNsTbeyS6suafndwpxIKOaEI96wqnwISRhpokJ4rt9tvIvlPSJB6g3tI8l
SZmZ7C1THQmQ+kaiq4rITQLRZIreaJ09p22axoojBfi1t7lLYLMUjnT6RSHt7vqzklXTgs5Xpq7F
LHMRbkra0M99LXPsMSF7riKZ3t17BK+zqRe9M87cNb9+Pe9UBKj09CnSy5mE2wQRV1wYDSEtmIig
8meBTnbKCz3baOdB3jNNEuBqYn6CnRflKZOhPi/qSjCRGUKvptS7qfEr62G+KzqEjWut/npPAjkQ
HFJ6yjFIUYBcKNrH/zGnEkaFOLA6/o51NrIJ3nV9pko/iQDFWPs7XbgxnU3KmGO0wEQeXhLzEisi
nqH4fWOIcP8SRf3oppJsMBt3SqjS+BSZNRydDx844nHVQXQcKLvOO3/FKY60iVW5TUGuaDBw/g70
7+cpFlVI07b+Mkg+8myorP/SG48iLJVBjURPxZzxr9P/Gw0w6vKJebCk927rqBNkxeao375xeUGD
LIAjp9sTenTTkNkUmEGPTkhqEM6sLgKmQG6CATRthWAmPazVn5SqPo4f9Fj2X5zSl2Zxg+HcSUlL
fNvzsD1hEzFtpn+yFOjcgqlzLoLaGaqohCLo1L74NHhlss3iFPS4W+x3PTK/Mos8axNUjpEAzWJD
5g4cnTxao+ZOrWsKcl57pWej0wwbuIFB7AIYRA25OYI3xzL+cg+RqgCKfq7DN0vFhEdCG7K7YOK9
uCnCViKWvOSBNlbytSQ2JVeefSWFLO1Qs21ZYMxDT7Zoxt3dXA47hCOPwuELn1IFqnNfisFfdsGG
vhFmI0m02ue2SZ+aOtmNN5C8+/BrztYThaXfCJiNe1MnVeRAtZktCZ7c4sOUQ4uDUNawWPluwXh4
Ouf8ZbpcFmcC81fRwSnRxpuogZLwgyEglhtQ2xH0UccoTI2RQGssNY13KTorP4viTJnWl/ZY6C44
LjzeTgczAW+524pSQBV6oWEmTg2H8c/O</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </saml2:EncryptedAssertion>
</saml2p:Response>


----------------------------------------------------------------------------------------------------------------------------------------------


On Mon, Dec 6, 2010 at 8:04 PM, Takuya Matsuhira
<[hidden email]> wrote:

> Thank you for noticing this site.
>
> I could decode the value of SAMLRequest.
>
> Regards,
>
> (2010/12/07 12:18), Brent Putman wrote:
>>
>>
>> On 12/6/10 9:53 PM, Takuya Matsuhira wrote:
>>>
>>> In one side, I can decode the the value of SAMLResponse this command.
>>> #cat samlresponse.txt |nkf --url-input -mB
>>
>>
>> No that doesn't work, as Scott said.  As he suggested, you should look
>> at the specs if you really want to know the technical details of the
>> binding.  There is however this online tool which handles this for you,
>> if all you care about is getting the message decoded:
>>
>> https://rnd.feide.no/software/saml_2_0_debugger/
>>
>>
>>
>>
>
>
> --
> +---------------------------------------+
> Takuya MATSUHIRA
> E-mail:[hidden email]
> +---------------------------------------+
>
>
Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Takuya Matsuhira
In reply to this post by Takuya Matsuhira
Thank you for your kind answer.

I have another question.

When I decoded the value of SAMLResponse,
two CipherValues were found.

-------
<saml2:EncryptedAssertion
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="_419000f87daad3fc0227c9d2552d1582"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xenc:EncryptedKey Id="_4252f19e29de62e48df0a0b0726c0026"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
</xenc:EncryptionMethod>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIFWTCCBEGgAwIBAgIQDbt74UJH173qR9YRm8m3HzANBgkqhkiG9w0BAQUFADCBtTELMAkGA1UE
.....
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:CipherValue>
axcmDmh/aVCNxYvSOQ8lSZ073vvAOZ++KyuOtncrOcu1FNxDrZuPtnk5tgvg+QNuXVHUgv9/vUjT
.....
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</ds:KeyInfo>
<xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:CipherValue>
Tk48E1g4gbw43F2u5c8bQlcsLfoHnIErlWwO9tPd2IIhN42s+0un2uk94IuXAcX04u2p2QJx+QZG
.....
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</saml2:EncryptedAssertion>
-------

I think both two values are encrypted.
But I want to check these values.

First value is encrypted by the public key of SP.
And Second value is encrypted by first value as common key.

I want to see the format of assertion.

So, Please teach me how to decrypt these values?


Regards,

(2010/12/07 13:04), Takuya Matsuhira wrote:

> Thank you for noticing this site.
>
> I could decode the value of SAMLRequest.
>
> Regards,
>
> (2010/12/07 12:18), Brent Putman wrote:
>>
>>
>> On 12/6/10 9:53 PM, Takuya Matsuhira wrote:
>>> In one side, I can decode the the value of SAMLResponse this command.
>>> #cat samlresponse.txt |nkf --url-input -mB
>>
>>
>> No that doesn't work, as Scott said. As he suggested, you should look
>> at the specs if you really want to know the technical details of the
>> binding. There is however this online tool which handles this for you,
>> if all you care about is getting the message decoded:
>>
>> https://rnd.feide.no/software/saml_2_0_debugger/
>>
>>
>>
>>
>
>


--
+---------------------------------------+
Takuya MATSUHIRA
E-mail:[hidden email]
+---------------------------------------+

Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Brent Putman
In reply to this post by Jason Rosenfeld


On 12/7/10 12:28 AM, Jason Rosenfeld wrote:
> I have a question which feels similar, but I don't think is the same
> as that being asked by Takuya.

Right, it's not the same.  He was asking about decoding a binding
message, you're asking about cryptographic decryption of the XML
Encryption of the SAML Assertion.


> I am running a Shibboleth SP and for debugging purposes am trying to
> get at a plain-text version of the AttributeStatement we are passed by
> an IDP as part of the SAMLResponse.  I have shibd logging turned up to
> debug mode such that it prints out a decoded version of the
> SAMLResponse, but with some IDPs there appears to be a further level
> of encryption within the SAMLResponse.  

Well, there's only one "level of encryption".  Either the returned
Assertion is encrypted, or it's not.  Don't confuse encryption with
Base64 encoding, or other kinds of encoding.

Shib IdPs encrypt the Assertion by default for SAML 2 (and don't and can
not for SAML1).  The IdP admin may choose to disable encryption
however.  And non-Shib IdPs might well behave completely differently.
Those variables likely account for the difference you are seeing.



>
> Is there a security reason why the Shibd logger can't or shouldn't
> print out a fully decrypted response to our log files?

No, not any that I can see, other than obvious things, like you're
receiving hypersensitive info as attribute data (password, SSN's, etc).


>  We obviously
> have this information fully decrypted at some point, but evidently it
> is after it gets written to the log.  If it is not possible to get a
> fully decrypted version of the AttributeStatement, I would at least
> like to know why.


Are you sure it's not in there?  I took a look at the SP code, and it
does log the decrypted assertion on level DEBUG.  However, it doesn't do
it as part of the Response logging, which just logs the received
Response protocol message as-is (e.g. with encryption intact).  It logs
each decrypted Assertion specifically and individually, later in the
processing flow. Look for a log line whose message begins with
"decrypted Assertion:" on category "Shibboleth.SSO.SAML2" (might want to
grep for it).  Based on where it is in the code, I'm not 100% sure
whether it will be in in shibd.log, as configured in shibd.logger, or in
native.log, as configured in native.logger, but I'd guess shibd.log.  If
you care to examine the code, it's in
cpp-sp/shibsp/handler/impl/SAML2Consumer.cpp.

Scott will correct me I'm sure if I've got any of the SP details wrong.


--Brent


Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Brent Putman
In reply to this post by Takuya Matsuhira


On 12/7/10 1:32 AM, Takuya Matsuhira wrote:

> Thank you for your kind answer.
>
> I have another question.
>
> When I decoded the value of SAMLResponse,
> two CipherValues were found.
>
>
> I think both two values are encrypted.
> But I want to check these values.
>
> First value is encrypted by the public key of SP.
> And Second value is encrypted by first value as common key.
>
> I want to see the format of assertion.
>
> So, Please teach me how to decrypt these values?


That's pretty much what Jason was also asking.  If you want to write
some XML decryption code (and have access to the SP's private key), you
could decrypt yourself.  That's a topic beyond the Shib user's list, though.

If you control the SP, I'd instead suggest just turning up the logging
in the SP to debug, per what I responded to Jason.  If you don't control
the SP, but do control the IdP: I don't think we currently have logging
of the assertion prior to encryption.  You can however turn off
encryption temporarily for that relying party, in relying-party.xml,
just to capture the message, and then turn back on.  Obviously you'd
have to weigh whether you can do that in production or not.
Instructions here:

https://spaces.internet2.edu/display/SHIB2/IdPXMLSigEnc


--Brent

Reply | Threaded
Open this post in threaded view
|

Re: I want to decode value of SAMLRequest

Takuya Matsuhira
Thank you very much!

I can just check the format of SAMLResponse.

So, I changed the value of "encryptAssertions", I could see
the contents.

Regards,

(2010/12/07 15:49), Brent Putman wrote:

>
>
> On 12/7/10 1:32 AM, Takuya Matsuhira wrote:
>> Thank you for your kind answer.
>>
>> I have another question.
>>
>> When I decoded the value of SAMLResponse,
>> two CipherValues were found.
>>
>>
>> I think both two values are encrypted.
>> But I want to check these values.
>>
>> First value is encrypted by the public key of SP.
>> And Second value is encrypted by first value as common key.
>>
>> I want to see the format of assertion.
>>
>> So, Please teach me how to decrypt these values?
>
>
> That's pretty much what Jason was also asking.  If you want to write
> some XML decryption code (and have access to the SP's private key), you
> could decrypt yourself.  That's a topic beyond the Shib user's list, though.
>
> If you control the SP, I'd instead suggest just turning up the logging
> in the SP to debug, per what I responded to Jason.  If you don't control
> the SP, but do control the IdP: I don't think we currently have logging
> of the assertion prior to encryption.  You can however turn off
> encryption temporarily for that relying party, in relying-party.xml,
> just to capture the message, and then turn back on.  Obviously you'd
> have to weigh whether you can do that in production or not.
> Instructions here:
>
> https://spaces.internet2.edu/display/SHIB2/IdPXMLSigEnc
>
>
> --Brent
>
>
>
>


--
+---------------------------------------+
Takuya MATSUHIRA
E-mail:[hidden email]
+---------------------------------------+