We will try and get to this soon. Thanks for your patience.

Until we are ready to launch, you can use https://iddev.fedorainfracloud.org/ for development purposes.
This supports the OpenID Connect Dynamic Registration, so you are able to register yourself for a Client ID there.

We're way past development at this point. We're coming up with more silly features to delay launching.

Until we are ready to launch

What does that mean? o_o

Hi, any updates please? :(

What's going on here? Can we get this rolled out to production so apps can register with id.fp.o with OIDC? This would also be very helpful for Communishift applications.

@ngompa this is just for a specific application.

@rhea do you mean to say that the development of this tool has completed, and it's ready for deployment? I didn't get that from the original request. Can you confirm? Since if it's still in deployment (as what I get from the README mentioning it as a milestone), iddev is more appropriate and you can register there yourself.

@puiterwijk So OIDC Dynamic Client registration is not a thing in id.fp.o at all?

@ngompa no, that is explicitly disabled. If you want that, please open a new ticket and we can reconsider.

It is in production. As I said half a year ago, there isn't anything else to do here, other than having something from you guys...

Helloes, I wanted to catch up - is there a production deployment now? The stage stopped working spitting out invalid scope errors.

If you want that, please open a new ticket and we can reconsider.

This is a ticket about that. We're using stage (in prod) as a workaround, which stopped working.

Moving to needs review so we discuss it at our monday standup.

We may need to gather some information to process the request. I thought we had a template, but I can't seem to find it now.

@kevin we have this: https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/ipsilon.html#create-openid-connect-secrets-for-apps which lists all the values we'll need to specify

And this comment from Patrick: https://pagure.io/fedora-infrastructure/issue/7679#comment-563793 which may be what you had in mind

Here is the information:

Which redirect URI(s) will the application use?

https://verify.valkyrja.app/signin-fedora

What is the application main URL?

https://verify.valkyrja.app/

Who will be the main contact for the application, or will this be core infrastructure?

Me or Rhea

What privacy policy will be applicable to the application, or will this be the standard

We are not storing any user data

Scopes

groups and CLA

Which authorization flow does the application use? [1]

code

Which token authentication method does the application use? [1]

RedirectGet

Ok, so the secrets have been generated and the ipsilon playbook ran successfully. I am however no able to see in openshift if the roll out ran fine or not.

So for all I can see, this is fixed.

I've just checked server side and the new config seems in place.

I'm going to close this ticket as fixed and please re-open or open a new one.

Sorry it took so long!

Hi @pingou, I think that I'm (we are) missing something. We don't have any access (or secrets) to id.fp.o for openidc, and the iddev.fedorainfracloud.org/openidc apprears to be missing the scopes still. (The certificate issue has been resolved though.)

I guess this is not actually done?

You need a copy of the secret? Can you send me you gpg key and I can encrypt them to you...

@kevin Ah I see what's the problem now...

Message contains error: 'invalid_scope', error_description: 'unknown scope https://id.fedoraproject.org/scope/groups requested'

If this is not a thing anymore we can remove it, we're not using it right now. (It was a future feature.)

I'm not seeing the scopes listed anywhere on the ipsilion configuration related to your credentials.

Looking at https://pagure.io/fedora-infra/ansible/blob/master/f/roles/mediawiki/templates/LocalSettings.php.fp.j2#_531-533 the scope seems to be valid

Not using that scope doesn't solve it because CLA is also invalid, and that one we actually need. Unless there is different way to verify whether the user signed cla?

This scope is used for groups, does the auth work if you don't ask for this scope?

Originally we ask for groups and cla - removing the groups still cracks up on cla scope. The idea is that we need to know who's a contributor (i.e. have CLA signed,) and ignore those that just created an account without CLA...

Originally we ask for groups and cla - removing the groups still cracks up on cla scope. The idea is that we need to know who's a contributor (i.e. have CLA signed,) and ignore those that just created an account without CLA...

Does it work if you're not asking for neither the groups nor the CLA?
If it doesn't the issue is likely on our side, if it does then maybe the issue
is in the way the scopes are requested.

Well... without any scopes it throws:

Message contains error: 'invalid_client', error_description: 'client authentication error', error_uri: 'error_uri is null', status code '400'.

Hi,

Until yesterday, iddev did not have the CLa and groups scopes enabled, and it looks like your app on https://verify.valkyrja.app/ still points to iddev?
Can you try pointing it to https://id.fedoraproject.org/ and see what the result is then?

Thanks,
Patrick

I think we have this finally working now. ;)

Please re-open or bug us if there is anything more we can do here. Sorry this took so long to get working. ;(

Something changed, it's all bork. Any clue why, what changed, any references would be appreciated.

This is likely fallout from the account system change. We no longer have a cla_done, but a 'fpca' 'agreement'.

@abompard can you adjust our end for this and tell @rhea what to adjust on their end please?

yeah, the CLA done scope doesnt exist anymore---

pretty sure if you need to check if a user has signed the FPCA -- you use the https://id.fedoraproject.org/scope/agreements scope.

Alternatively, all users that have signed the FPCA are also automatically in the signed_fpca group, so you can use the https://id.fedoraproject.org/scope/groups scope and check if the user is a member of that group.

Note too that https://iddev.fedorainfracloud.org/ is currently not up-to-date with the new Fedora Accounts infra.

If you need to develop locally with something like iddev -- try tiny-stage maybe?

https://github.com/fedora-infra/tiny-stage

I never mentioned using iddev and we're not using it.

I'd also appreciate more stable systems that don't change every 3 months, I (or anyone else) can't keep up with this.

I'd also appreciate more stable systems that don't change every 3 months, I (or anyone else) can't keep up with this.

Well, we have been working on the next generation of account system since about 2011... it just happened that we deployed it finally this year. I don't expect any changes/instability in the forseeable future after this.

https://id.fedoraproject.org/scope/agreements

What's the value like?

Hello! I think the simplest would be to get the groups and check that the user is in the signed_fpca group.

@rhea Did that get it working? Or if not, could we perhaps get you and @abompard together on irc/matrix/something and get it solved?

Yes I hacked it up, thank you.

Great. Sorry again for the hassle. ;(