Fedora Project would love to have openid support available for Fedora and Fedora EPEL maintainers, users and qa folks to use with our Fedora openid provider.
* Would allow users to authenticate to our openid provider, so they don't need to create/maintain another login/password in bugzilla.
* Would allow us to not have to maintain a script to sync permissions for fedora contributors that need permissions (openid could just return that group information to bugzilla). Would reduce load running that script all the time.
* If we allow any openid provider, it would allow a lower barrier to entry to file bugs for new users (no need to create a bugzilla account, just use openid) while still giving us an email address to contact the user via. This might be a nice PR win making us more accessable. Might also allow more upstream folks to comment since they don't need to make an account.
* would be a non upstreamed plugin to maintain.
* would need to make sure it does not affect/change any groups that are not Fedora related.
We would of course want to restrict the groups that openid would be allowed to authenticate a user for to only Fedora related ones. All RHEL or other groups would still need to keep their own accounts, etc.
Upstream bugzilla seems to have moved to 'persona' support. This could work with our provider, but it's not ideal as it's only email address (no group information).
There's a openid plugin at:
and more information about upstream and openid at:
Happy to answer questions or provide more information on this.
Thanks for your consideration.
In case of any questions regarding OpenID implementation in the Fedora Infrastructure, I can provide any info wanted on that.
Just as an update here, our fedoauth provider now fully supports persona.
I don't know if that would do everything we need, but if it's easier from a support side we could investigate that? I know Patrick would be happy to answer any questions around that.
Was looking to see if anyone had requested, but.... 1125081 is private.
(In reply to Jason Tibbitts from comment #3)
> Was looking to see if anyone had requested, but.... 1125081 is private.
1125081 is a similar request for authenticating another group of users via another auth mechanism. That means that we'll need to implement this in a way that supports multiple authentication mechanisms. Presumably we'll need to cascade through them in a deterministic order, with the basic Bugzilla auth last. We'll need to be mindful of performance/responsiveness when we implement this.
Please note that as of a few months ago, Fedora also provides SAML2.
(In reply to Patrick Uiterwijk from comment #5)
> Please note that as of a few months ago, Fedora also provides SAML2.
I've tried googling for the Fedora SAML2 details but could't find anything, anyone have a docs link?
I'm currently working on SAML2 for Red Hat authentication, so being able to test Fedora SAML2 at the same time would be a good extra test and streamline this bug.
(In reply to Jeff Fearn from comment #6)
> (In reply to Patrick Uiterwijk from comment #5)
> > Please note that as of a few months ago, Fedora also provides SAML2.
> I've tried googling for the Fedora SAML2 details but could't find anything,
> anyone have a docs link?
> I'm currently working on SAML2 for Red Hat authentication, so being able to
> test Fedora SAML2 at the same time would be a good extra test and streamline
> this bug.
These details are not public at the moment, but if you give me the expected host name I can issue a certificate that gives access to our staging SAML instance.
Or, if you already have a certificate, just passing your current metadata is good enough for us.
You can find our SAML metadata at https://id.fedoraproject.org/saml2/metadata
And for staging: https://id.stg.fedoraproject.org/saml2/metadata
(In reply to Patrick Uiterwijk from comment #7)
> These details are not public at the moment, ...
Correcting my phrasing: everything about this setup is public.
Only the documentation is missing at this moment, but it's "plain old SAML2", powered by Ipsilon.
@Jeff, Could you guide me how to test this bug?
(In reply to Rony Gong from comment #11)
> @Jeff, Could you guide me how to test this bug?
I believe that testing this is currently blocked on the QE web server and the Fedora devel IDP both having signed certificates. It might also be blocked on someone from QE having a FAS account and that being enabled on the FAS devel IDP.
Once they both have signed certs then the QE server will need to be configured:
1: Administration -> SAML2Auth IdP Settings
2: Add a new entry:
Name: Fedora Account System
Assuming you are using the latest versions of my Ansible repo, you can logout and when you when you login the FAS option should be in the box of login options.
You may need to restart apache for that to take effect.
If not then you have to tweak the parameters.
user_verify_class: Make sure SAML2Auth is at the top of the active list
This assumes you are using the standard locations and have imported all the CA's as normal. i.e. the certoificates are set-up as per Ops and IT standard practices.
You may need to restart apache for that to take effect.
Once the QE server is set-up and working login attempts will fail until Peter imports the QE web server's SA meta data. He can get this data from $server://saml2_metadata.cgi which is why it's easier to set-up the SA before the IDP.
Needinfoing Peter for his input on the FAS devel server and if my information about it is accurate.
New certificate has been provided.
Tested on QA environment(5.0.3-rh6)
1.Open the fedora page https://fedoraproject.org/wiki/Join to login
1.Click the link 'Fedora Account System' in the login dialog box
==>Redirect to new page with error:
500 - Internal Server Error
Ipsilon encountered an unexpected internal error while trying to fulfill your request.
Please retry again.
If the error persists, contact the server administrator to resolve the problem.
This is working for me, it might have been a temporary issue with the IDP.
@Jeff, Could you try to login by fedora account on qe server:
Same error as before.
I get this:
Your attempt to authenticate using this email address "email@example.com" on the chosen IDP has been forbidden by the site administration; it does not match the specified regular expression "^(?!.*@redhat.com)".
Which is correct, I don't have a non-redhat account to try it on.
It works now after I do more setting(finish contributor agreement)to my test account. Thanks
Tested on QA environment(5.0.3-rh8)