issue with research.gov ?

[IAM David Bantz]

That's an interesting hint David.  The request received by my IdP has 2
contexts listed in the request:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol ...>

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://identity.research.gov/sso/sp</saml:Issuer>
...
<samlp:RequestedAuthnContext Comparison="exact"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:
*ac:classes:unspecified*</saml:AuthnContextClassRef>
  <saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:
*ac:classes:PasswordProtectedTransport*</saml:AuthnContextClassRef>
 </samlp:RequestedAuthnContext>
...

I'm returning for my own login attempt an indication of MCB/duo in
AuthnContextClassRef:

... <saml2:AuthnStatement ...>
      <saml2:AuthnContext>
         <saml2:AuthnContextClassRef>*https://iam.alaska.edu/trac/wiki/mfa
<https://iam.alaska.edu/trac/wiki/mfa><*/saml2:AuthnContextClassRef>
      </saml2:AuthnContext>...

and for non 2-factor user, I'm returning simply "Password" in
AuthnContextClassRef:

 ...  <saml2:AuthnStatement ...>
      <saml2:SubjectLocality Address="137.229.40.130"/>
      <saml2:AuthnContext>
       <saml2:AuthnContextClassRef>
*urn:oasis:names:tc:SAML:2.0:ac:classes:Password*</saml2:AuthnContextClassRef>
     </saml2:AuthnContext>...

I should be forcing the context to PPT?

How do I do that for an SP?

David Bantz



On Tue, Aug 18, 2015 at 12:48 PM, David Langenberg <davel at uchicago.edu>
wrote:

> What authncontext are you sending to them?  Research.gov has an odd
> requirement that you must send PPT even though they don't request it.
>
> Ave
>
>
> On Tuesday, August 18, 2015, Kevin Foote <kpfoote at uoregon.edu> wrote:
>
>>
>>
>> > On Aug 18, 2015, at 12:51 PM, IAM David Bantz <dabantz at alaska.edu>
>> wrote:
>> >
>> > We set up federated (via InC) access to NSF and research.gov quote a
>> while ago. An email from an NSF contractor 5 Aug requested testing of "new
>> authentication technology" from which I discovered our institution's
>> federated login attmpts now fail with the sole information in the browser
>> "Single Singn On failed"; for all I know this may have been in fail state
>> some time prior to this request and whatever change was made at
>> research.gov.
>> >
>> > Are others experiencing any problems with Shibb-InC federated access to
>> research.gov or is it just our IdP?
>> >
>> > (I'm asking here because over 2 weeks since providing my logs to them
>> showing outgoing SAML assertion, the only responses I've pried from NSF are
>> "reboot your computer and try again" and "are your credentials registered
>> with InCommon?”)
>>
>> Hi David,
>>
>> I can’t say that I’ve had as much trouble as you.
>> I acted on the email that you referred to in your message and I got a
>> similar “failed” message. I replied to the said address with the results
>> and heard nothing - still nothing.
>> However I tried a few days later and all worked.
>>
>> AFAIK it is still working as well, no complaints and a few general
>> population logins for the service.
>>
>> --------
>> thanks
>>  kevin.foote
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>
>
>
> --
> David Langenberg
> Identity & Access Management Architect
> The University of Chicago
>
>
> --
> 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/20150818/2883c4e8/attachment-0001.html>