box.com / IDP 3.x

[Andrew Morgan]

Alan,

My coworker filled out the Box SSO questionnaire.  This is what I asked 
him to put in the form:

--------------------------------------------------------------------
I have attached our metadata.  Here is what we want in those fields:

email: urn:oid:1.3.6.1.4.1.5923.1.1.1.6
first name: urn:oid:2.5.4.42
last name: urn:oid:2.5.4.4

We won't use the Groups attribute for now, so leave that blank.

I don't see an option on the form, but we also want to request they 
support encrypted assertions.  From the NET+ Box page:

"By default, Box expects SAML assertions to be unencrypted. Optionally, 
they will support encrypted assertions (such as Shibboleth), however, this 
support must be specifically requested as part of their SSO 
configuration."

If you get a chance to add a comment or something, please specify 
encrypted assertions. 
--------------------------------------------------------------------

I sent along our IDP metadata file too, which I think they loaded.

Make sure they are using the OIDs for the attributes and make sure your 
encryption settings match.  We asked them to enable encryption.

 	Andy

On Thu, 9 Jun 2016, Powell, Alan wrote:

> Thanks Andrew and Scott
>
> After Scotts response, it was clear I should basically just be able to
> release the attributes and be good (possibly having to consider encryption
> assertions versus unencrypted). At this point, I am doing exactly what you
> suggest works and it doesn¹t work so my assumption is a problem with their
> configuration. Since they manually add IDP metadata, I chose to use a test
> IDP 3.x instance rather the IDP I have in the InCommon metadata and I
> suspect this might be part of the problem. We are only in the 45 day trial
> period, however, and the ³technical² person we have working with us knows
> very little about SAML so I am just going to wait until we sign the
> contract etc. At that point, I should be moved over to IDP 3.x and my
> InCommon metadata will match the IDP I am trying to use to get this to
> work, etc..
>
>
>
> On 6/8/16, 8:03 PM, "users on behalf of users-request at shibboleth.net"
> <users-bounces at shibboleth.net on behalf of users-request at shibboleth.net>
> wrote:
>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 8 Jun 2016 11:05:18 -0700 (PDT)
>> From: Andrew Morgan <morgan at orst.edu>
>> To: Shib Users <users at shibboleth.net>
>> Subject: Re: box.com / IDP 3.x
>> Message-ID:
>> 	<alpine.DEB.2.02.1606081051360.12016 at shell.onid.oregonstate.edu>
>> Content-Type: text/plain; charset="iso8859-7"; Format="flowed"
>>
>> On Wed, 8 Jun 2016, Powell, Alan wrote:
>>
>>> We are testing box as an InCommon member. I can?t get authentication to
>>> work even though it appears I am doing the right thing. My preference
>>> is
>>> to make sure it works with IDP 3.x. Can anyone who is using box provide
>>> any insight, ideally with IDP 3.x?  Does anyone see anything wrong with
>>> what I am doing?
>>>
>>> The examples I?ve encountered seem to just indicate you do the typical
>>> Shib thing of releasing attributes but don?t you need to have the email
>>> be in the SAML subject in addition? (ie
>>> xsi:type="enc:SAML2StringNameID"
>>> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>>> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> )
>>
>> Nope, you don't need to release a particular NameID.  Box will use
>> attributes.  I'm releasing eduPersonPrincipalName, surname, givenName,
>> and
>> mail.  The NameID that I'm sending is a transient ID.  I'm also using the
>> defaults for encryption or signing (SHA256).
>>
>> I am using Box's InCommon metadata.
>>
>> Perhaps the problem lies on the Box side of the configuration?
>>
>> 	Andy
>>
>> ------------------------------
>>
>
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>