AWS AppStream

[Hong Ye]

Hi Tom,

We ended up with using a modified local copy of AWS metadata. We reported the problem to AWS. So far haven't seen them making any changes. We also requested them to support xml encryption two weeks ago. They put it as feature request and doesn't give any estimate.

Thanks for providing a solution. I'll try that.

Hong

On 3/20/18, 12:18 PM, "users on behalf of Tom Scavo" <users-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:

    Hi Hong,
    
    It's been a long time since you started this thread but I had no
    solution to offer until now.
    
    On Fri, Aug 4, 2017 at 11:17 AM, Hong Ye <hy93 at cornell.edu> wrote:
    > I tried configure IDP release urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress format nameID with relying party overwrite. But with nameID format requirements in  their metadata, no nameID was released.
    >
    > <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{
    >             'urn:amazon:webservices'
    >             }}" >
    >
    >             <property name="profileConfigurations">
    >                 <list>
    >                     <bean parent="SAML2.SSO" p:encryptAssertions="false" p:nameIDFormatPrecedence=" urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress " />
    >                     </list>
    >             </property>
    > </bean>
    
    For the archive, the above NameIDFormat is incorrect. The correct format is:
    
    urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    
    > If I removed their nameID format requirements from it’s metadata,  then aws login works fine. The problem is AWS refresh their metadata every year. I tried to avoid manually modify their metadata .
    
    Yes, that's a tricky combination of issues. At the time you posted
    your problem, there didn't seem to be any good solution. I'd be
    curious to know how you eventually solved this problem.
    
    In any case, I've documented a solution that uses an XSL script to
    remove the offending NameIDFormat elements from metadata:
    https://wiki.shibboleth.net/confluence/x/FoWqAg
    
    The XSL script combined with a Shibboleth LocalDynamicMetadataProvider
    allows you to semi-automate a metadata refresh process for AWS
    metadata. That's the best you can do, I think.
    
    Note that AWS metadata does not include an encryption certificate. At
    the time you posted your question, this went unnoticed. Today this
    will be seen as a serious omission but I'm afraid only AWS can do
    anything about it.
    
    If you have questions, let me know.
    
    Tom
    -- 
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net