The login in PDC doesn't work for some time (it probably never worked with FAS 2.0). Last time I needed a token for PDC @kevin generated it for me outside of the UI.

So we either wait till @kevin will be back and he could do it manually or we can fix the authentication on current PDC. But because PDC is something we want to retire anyway in the future, I will be for first option.

I agree with your opinion, let's wait for @kevin

So, we do have SAML2 data for this, but it says I note: "validUntil="2016-09-27T23:42:32Z""

Why did you need to login?

I think if this is an app/releng process we can perhaps make a token in the db.

I'd prefer to get rid of pdc than to fix it.

@amedvede Do you still need this solved?

@kevin I don't need to login, I just need a token to make changes in PDC.
@zlopec Yeah, still need this.

So, I'm unclear on what changes you want to make... is this for a script or just releng stuff?

But that said, SAML2 is broken on pdc... it seems that we don't have any data for it in ipsilon. ;(

Perhaps @abompard could tell why? we don't seem to use the saml2_data in ansible, we get it from ipsilon, and I am not sure where ipsilon gets it. ;(

This data seems to be in ansible, in roles/ipsilon/templates/saml2_data. There is a pdcprod entry in there.

Ipsilon is rejecting PDC's token with the error "Invalid or missing signature algorithm DsInvalidSigalgError()". I'll investigate some more.

Yeah, its in ansible, but... from what I can see we never use that saml2_data file anywhere?

There's a script on ipsilon servers to pull that data from the ipsilondb, but pdc is... not in there.

Yeah the file is loaded by a macro in the configuration.conf template.

From what I see it may be something like PDC using sha1 and ipsilon not accepting it. I've tried to make it use sha256 but to no avail yet.

That's not it, the signature is absent from PDC's SAML requests. I noticed the certificates in ansible-private at files/saml2/pdc.fedoraproject.org/certificate.pem and in saml_data are expired, and have been since 2017. Should I renew them? Is anyone able to connect to PDC with SAML at the moment?

I'm not sure if you should renew it. If it will take a lot of effort I don't need it probably. I will write the script without using a token, after that during the testing on stg it will probably use the existing one, so this ticket can be closed if you don't want to continue the conversation of course.
@kevin I need it for script, that automates one of SOP's .

Ha. Well, renewing shouldn't be too hard? It would be nice to have it work again...

No SAML2 auth is not working against pdc at all that I know of. We are using tokens for things we do, which are seperate. But you can't make a new token until you login... ;(

Ideally the cert should come from IPA I suppose, but for now I'll just go with the PKI in ansible-private.

Oooookay, I got to the bottom of this very rabbit hole. What was needed was:

• generate a new certificate for pdc
  • fix the pkitool scripts in the process, they assumed a directory path for the user's git clone
• regenerate the metadata.xml file that mod_auth_mellon needs, and provides a script for.
  • Updating the value of the certificate in the file was not enough, otherwise mod_auth_mellon would not sign the SAML requests and Ipsilon would reject them. This one took quite a while to figure out.
  • unfortunately the script that mod_auth_mellon provides for this purpose generates its own cert, so I had to write a new script based on it to accept our existing certificates
  • the metadata.xml that is deployed lives in ansible-private, but since we now generate it, remove it from there
• update Ipsilon's metadata for PDC in saml2_data (Ipsilon's configuration format wants it all on one line, by the way. Easy is boring.)
• SAML2 login worked at that point, but the username that PDC was using was a random string, different on each login. I've updated the mod_auth_mellon config file to use the username instead.

Since I was a bit annoyed by the amount of manual steps and copy-paste required to do this, I improved the playbooks:
- the PDC metadata is automatically regenerated when the cert file changes
- the PDC metadata in Ipsilon's config is retrieved by the playbook and inserted (on one line) in the configuration file.

Hopefully that will make the life of some sysadmin easier in the future.

@abompard It would be also nice to add this to PDC SOP

I can confirm it works now here. ;)

The doc on how to get a token out of it is part of https://docs.pagure.org/releng/sop_unretire.html (and boy it's fun... get a auth thing, run a weird curl command to generate a token, etc).

Also, after you do that and have a token, it has no permissions, so you have to go into the database and set 'is_superuser' to 't' for that user/token.

Happy to close this once we decide what docs we should have...

I've added the procedure to regenerate SSL certs to the PDC SOP: https://pagure.io/infra-docs-fpo/c/1f6e9b8cbde7b3be441cec91f7a45dc2764dcbf4?branch=master.

The doc on how to get a token out of it is part of https://docs.pagure.org/releng/sop_unretire.html (and boy it's fun... get a auth thing, run a weird curl command to generate a token, etc).

Oh gosh this is horrible. Should I try to do something about it or do we just focus on getting rid of PDC?

@abompard The best option would be to get rid of PDC, but we didn't get to that yet. Luckilly the new token isn't requested that often.

@kevin yeah now it's working thanks for helping, and btw, maybe it will sound stupid, but can I find the database?
@abompard Thanks for fixing this!

Yeah, lets just put our effort into killing pdc. ;)

The database is on our shared postgresql host... db01.iad2.fedoraproject.org...

I guess we can close this now? Please re-open if I forgot anything we needed to do here.