The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Paetow <Stefan.Paetow AT jisc.ac.uk>]

Just FYI gents, 

We're starting to pick up tickets related to this, i.e. suddenly some of our 
members' admins find themselves without an institution to administer. 

I've requested more information from them to ascertain what the problem is, 
but at the moment we're re-onboarding them as and when the problem occurs.

Stefan Paetow
Federated Roaming Technical Specialist

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp AT jabber.dev.ja.net
skype: stefan.paetow.janet


In line with government advice, at Jisc we’re now working from home and our 
offices are currently closed. Read our statement on coronavirus 
<https://www.jisc.ac.uk/about/corporate/coronavirus-statement>.

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. 
GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, 
Bristol, BS2 0JA. T 0203 697 5800.
 

On 18/02/2021, 07:26, "cat-users-request AT lists.geant.org on behalf of 
Miroslav Milinovic" <cat-users-request AT lists.geant.org on behalf of 
miro AT srce.hr> wrote:

    Vlad,
    
    you've identified one potential problem. We can handle that but want to
    be sure we've done it in a right way.
    
    Miro
    
    
    On 18-Feb-21 01:14, Vlad Mencl wrote:
    > 
    > 
    > On 18/02/21 12:06, Miroslav Milinovic wrote:
    >> Hi Vlad,
    >>
    >> Thanks for you input.
    >>
    >> Earlier we did such a change which ended with problems for some other
    >> IdPs (yes, legacy problem)
    > 
    > It may potentially cause issues if IdPs that currently send EPTID start
    > sending samlPairwiseID alongside it - and IFF monitor.eduroam.org starts
    > picking up samlPairwiseID instead.  And the users suddenly end up with
    > "new" identities.
    > 
    > But such migration issues can be solved (or parked for later) by
    > carefully choosing the order in which ID attributes are checked.
    > 
    > I.e., it can be possible to prefer EPTID over samlSubjectID to avoid
    > breaking identities for now ... but the identities will have to break at
    > some point in time in order to migrate the users from the deprecated
    > EPTID to the new attributes.
    > 
    >> Please allow us few days to test and check outcome of the change you
    >> propose. I'll let the list know once it has been done.
    > 
    > Thanks - I look forward to hearing from you!
    > 
    > Cheers,
    > Vlad
    > 
    >>
    >> Miro
    >>
    >>
    >> On 17/02/2021 21:26, Vlad Mencl wrote:
    >>>
    >>> Hi  Matti, Miro,
    >>>
    >>> I'm in a very similar situation (except for I'm still preparing the
    >>> rollout of samlSubjectId / samlPairwiseId).
    >>>
    >>> However, the samlSubjectId / samlPairwiseId attributes specify a
    >>> standard method of requesting these attributes (via dedicated
    >>> EntityAttributes in the SP metadata).
    >>>
    >>> And the monitor.eduroam.org SP (which acts as a gateway for
    >>> cat.eduroam.org) is not using this method.
    >>>
    >>> It would be a significant waste of everyone's time if each IdP had to
    >>> configure the IdP release manually - we would be back to square one 
with
    >>> all attribute release efforts.
    >>>
    >>> Miro, can you please add the entity attribute to the SP metadata?
    >>>
    >>> As per
    >>> 
https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html#_Toc536097237,
    >>>
    >>> the SP should have EntityAttribute
    >>> "urn:oasis:names:tc:SAML:profiles:subject-id:req" with the right 
value -
    >>> "any" if either samlSubjectId or samlPairwiseId is sufficient.
    >>>
    >>> I.e.,
    >>>
    >>>       <saml:Attribute
    >>> Name="urn:oasis:names:tc:SAML:profiles:subject-id:req"
    >>> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    >>>           <saml:AttributeValue>any</saml:AttributeValue>
    >>>       </saml:Attribute>
    >>>
    >>> Shibboleth IdP default config includes rules for releasing 
samlSubjectId
    >>> / samlPairwiseId based on this attribute - so this should work right
    >>> away for any IdP supporting these attributes.
    >>>
    >>> I hope this can be done.
    >>>
    >>> Cheers,
    >>> Vlad
    >>>
    >>>
    >>>
    >>> On 18/02/21 01:51, Matti Saarinen wrote:
    >>>>
    >>>> Hello,
    >>>>
    >>>> Our IdP admins did now configure our IdP to send pairwise-id. Now, 
the
    >>>> issue changed.
    >>>>
    >>>> I used to be able to manage the IdP of University of Helsinki. Now, 
the
    >>>> server replies "You are not managing any Identity Provider." Very
    >>>> likely
    >>>> this is due the fact that the value sent with pairwise-id is 
diffrerent
    >>>> from the one that was sent with eduPersonTargetedID. Should I contact
    >>>> FUNET and ask them to invite me to manage our IdP again? Or is there
    >>>> any
    >>>> easier way?
    >>>>
    >>>> Cheers,
    >>>>
    >>>> Matti
    >>>>
    >>>>> actually this service needs at least one of the following
    >>>>> attributes to
    >>>>> identify user: eduPersonTargetedID, pairwise-id, subject-id,
    >>>>> facebook_targetedID, google_eppn, linkedin_targetedID,
    >>>>> twitter_targetedID.
    >>>> To unsubscribe, send this message:
    >>>> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
    >>>> Or use the following link:
    >>>> https://lists.geant.org/sympa/sigrequest/cat-users
    >>>>
    >>>
    >>
    >>
    > 
    To unsubscribe, send this message: 
mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
    Or use the following link: 
https://lists.geant.org/sympa/sigrequest/cat-users