Decoding encrypted attributes from an IDP

[Yannick Béot]

Hi,

.crt or .pem does not matter. What is import is that the file starts with
"#######..."

How did you generate the metadata you sent to your IdP?

Y.

On Tue, Jul 24, 2012 at 2:28 PM, Rob Whitener
<rob.whitener at audaxhealth.com>wrote:

> This is helpful.  I don't have a key and cert in PEM format.  I just have
> a .key and a .crt (well, at least I don't think I have it in PEM format).
>  I will look into this some more.
>
> When I run the openssl command against the cert, I do get back that
> information.
>
>
> On Tue, Jul 24, 2012 at 3:45 AM, Yannick Béot <yannick.beot at gmail.com>wrote:
>
>> I would not bother about the UUID.
>> Inside your shibboleth configuration, you should have something like
>>  <CredentialResolver type="File" key="sp-key.pem"
>> certificate="sp-cert.pem"/>
>>
>> Use the following openssl command to get the subject of the certificate:
>> openssl x509 -in sp-cert.pem -subject -noout
>>
>> You should see something like
>> subject= /EMAILADDRESS=cloudops at audaxhealth.com/ CN=www.dev.careverge.com/OU=Cloud
>> Ops/O=Audax Health Inc./ L=Washington/ST=District of Columbia/C=US
>>
>> How did you get the metadata you sent to your IdP?
>>
>> In any case, I would to try to exchange again the metadata.
>>
>> Y.
>>
>>
>> On Mon, Jul 23, 2012 at 10:54 PM, Rob Whitener <
>> rob.whitener at audaxhealth.com> wrote:
>>
>>> Its hard to tell. I have this in the assertion for the encrypted
>>> assertion:
>>>
>>> </EncryptionMethod><ds:KeyInfo><EncryptedKey
>>> Id="uuidb5469dbb-0138-1020-ab16-fef9662dd66c"><EncryptionMethod Algorithm="
>>> http://www.w3.org/2001/04/xmlenc#rsa-1_5
>>> "></EncryptionMethod><ds:KeyInfo><ds:KeyName>EMAILADDRESS=
>>> cloudops at audaxhealth.com, CN=www.dev.careverge.com, OU=Cloud Ops,
>>> O=Audax Health Inc., L=Washington, ST=District of Columbia,
>>> C=US</ds:KeyName>
>>>
>>> Where it looks like the encrypted key is being looked up by UUID.  There
>>> is a key in the asswertion, but the assertion indicates it is used for the
>>> signature.  Comparing the key in the assertion to the keys in the IDP
>>> metadata, it looks like the same key that is used for both encryption and
>>> signing (odd).  I have no UUID indicators in the metadata anywhere, so I am
>>> not sure if there is another way to see either what the UUID is indexing or
>>> how it is being used.
>>>
>>> Thanks,
>>>
>>> Rob
>>>
>>>
>>> On Mon, Jul 23, 2012 at 4:30 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>>
>>>> On 7/23/12 4:14 PM, "Rob Whitener" <rob.whitener at audaxhealth.com>
>>>> wrote:
>>>> >
>>>> >At Scott Cantor's suggestion, I asked our partner to encrypt the whole
>>>> >assertion, rather than just the attributes (they took it upon
>>>> themselves
>>>> >to have the attributes remain encrypted as well, inside the already
>>>> >encrypted assertion? Seems like too much encryption
>>>> > to me).
>>>>
>>>> It also won't fix your issue, although...
>>>>
>>>> >Now, we are seeing errors like this in Syslog:
>>>> >
>>>> >Jul 23 19:18:21 ip-10-90-230-192 shibboleth-sp: 1343071101 ERROR
>>>> >Shibboleth.Listener [24585] shib_check_user: remoted message returned
>>>> an
>>>> >error: A valid authentication statement was not found in the incoming
>>>> >message.
>>>>
>>>> That means you can't decrypt with the key they used, as Nate said, and
>>>> that should also be happening in the original case of the
>>>> EncryptedAttribute (not in syslog, it will just be a warning in
>>>> shibd.log).
>>>>
>>>> -- Scott
>>>>
>>>> --
>>>> To unsubscribe from this list send an email to
>>>> users-unsubscribe at shibboleth.net
>>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list send an email to
>>> users-unsubscribe at shibboleth.net
>>>
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120724/bb0e2fd1/attachment.html