In order to put this item on the Bugzilla roadmap and provide a meaningful estimate of the development and QE work we need a more detailed statement of requirements.  In particular:

1. Are you asking for existing Bugzilla users to be authenticated via an external authentication service, or for users not known to Bugzilla to be authenticated, or both?

2. If logging in existing Bugzilla users, do the customer portal accounts have the same user id as Bugzilla (user email addresses)?

3. If the user id's are not identical, how should Bugzilla map customer portal users to existing Bugzilla users (and is Bug 1240363 related to this)?

4. If logging in users not known to Bugzilla, what information should those users be allowed to see, and what (if anything) should they be allowed to change?

5. Will the SAML service be reachable from outside the Red Hat firewall?

Answers:

1.  Yes, these are for existing bugzilla users who have authenticated external from bugzilla via the customer portal (access.redhat.com).  

2. No. user IDs are different (email addresses aren't used).

3. I wonder what data is set in the auth cookie returned from access.redhat.com.  Dan Fisher may have some ideas on how to map this.  No, this is not related to Bug 1240363

4. If users don't have a bugzilla account then their access should be read-only.  They should be able to see any bug within the customer confidential group (see Bug 1238762)

5. Yes

I'm afraid SSO is not something I'm particularly conversant in.

And in fact, it's been a struggle trying to engage folks from IT who are in charge of SSO.
I am going to mark this NEEDINFO on Mike Moore (my manager) as I believe he may be able to steer this conversation.

With those qualifications out of the way, I'll editorialize:

I suspect the cookies represent a poor way to pursue this...

*and*

I believe that this exercise will require a LARGE amount effort as some person (or persons) takes each Bugzilla user record, looks at their email address (or some other identifying attribute or set of attributes) and then tries to find an equivalent SSO Username with matching (or similar enough) attributes.

The end result would be glorious (a true single-sign on! where reporting on customer activity can span not just Portal, but also Bugzilla!), but because there's such a long history of Bugzilla logins + SSO Usernames existing independently of each other, it'd take a CONSIDERABLE amount of effort.

(Of course, it's not going to get any easier in the future, so we may as well start now)

(In reply to Daniel Fisher from comment #3)
> (Of course, it's not going to get any easier in the future, so we may as
> well start now)

Unless it's already too expensive in which case we should make a sane business decision and close this, wontfix too expensive.

(In reply to Jeremy West from comment #2)
> Answers:
> 
> 1.  Yes, these are for existing bugzilla users who have authenticated
> external from bugzilla via the customer portal (access.redhat.com).  
>
> 2. No. user IDs are different (email addresses aren't used).

If there is no way to map email address to a portal account then this can't be automated.

> 3. I wonder what data is set in the auth cookie returned from
> access.redhat.com.  Dan Fisher may have some ideas on how to map this.  No,
> this is not related to Bug 1240363

bugzilla.r.c doesn't have access to the access.r.c cookies and I'd be surprised if this changed.

I logged in to the portal and there is nothing in the cookie that is usable for mapping, but this doesn't mean there isn't something in the SAML transaction that would allow this.

> 4. If users don't have a bugzilla account then their access should be
> read-only.  They should be able to see any bug within the customer
> confidential group (see Bug 1238762)

This isn't an option with the current code base and it would be extremely expensive to implement and maintain. It would be much less expensive to just create them an account and pop them in the group.

> > 2. No. user IDs are different (email addresses aren't used).
> 
> If there is no way to map email address to a portal account then this can't
> be automated.

SSO User records do have email addresses, I strongly suspect that the relationship of the two sets of email addresses (SSO User records and Bugzilla User records) won't map cleanly 100% of the time.

What the percentage is, should be investigated...
Although I'm not sure who is going to put the resources forward to do that investigation.

> > 3. I wonder what data is set in the auth cookie returned from
> > access.redhat.com.  Dan Fisher may have some ideas on how to map this.  No,
> > this is not related to Bug 1240363

As stated before, I know precious little about SAML+SSO.
I'm going to bring Chris Bredesen into this conversation to see if he can point this conversation in a useful direction.

A few thoughts here, responding to multiple comments.

* SSO cookies are not set by access.r.c; they are set by idp.r.c using redhat.com as the domain. BZ should be able to read the genearl user cookie but not the IDP session cookie; this is by design.

* Red Hat Logins (they are not portal accounts; we just use the same scheme as all the other redhat.com services) do have email accounts but they are not 1:1; there is no uniqueness forced on accounts created such that an email gets used only once. This is going to be problematic.

* This is going to take more than a BZ thread to sort out initially; I suggest a call with myself, Jared Sprague, someone from the IAM team under Vikas Kumar, someone like Dan F and someone from the BZ team at a minimum.

I would LOVE to see this happen and I'm all-in on helping out however possible.

I would personally vote for a merge of the realms, one time, with scripts or web prompts to handle the exceptions, leaving BZ auth in the dust. That's just me though :)

Here's a agreed workable solution after a call and email discussion among  Chris Bredesen, Daniel Fisher, Jared Sprague, Muhammad Tahir, Josh Cain, Dustin Minnich, Jeff Fearn & Pushpa Chinnappa.

* Bugzilla adds a login via SAML option to the UI
* If someone clicks that then BZ does the SAML shuffle
* When SAML returns BZ sees if the SAML login maps to a BZ login
* If it does, you are logged in, have a nice day
* If it doesn't it offers the user a choice to create a new account or link to an existing account
(Josh Cain: When you say "it", are you envisioning BZ standing up this functionality or proxying with an app in front of BZ?
Jeff Fearn: We'd just do it in Bugzilla)
* If new then it moves to the create an account page and ensure the accounts are linked
* If existing then it asks the user for their BZ login details and if that passes it links the accounts
* If it fails we break tradition and be polite about it

We can make the text on the choose an account page inform the user it's a once off action.

Jeff Fearn: I've not worked with SAML, but it may be possible for BZ to detect if there is a SAML token and automate some actions if it finds one.
I imagine from our end the hard part of that would actually be getting BZ to talk to SAML, the work flow once that was done would be relatively easy on our side.

Chris Bredesen: This is the sensible solution and in fact nearly identical to what we're doing with MS Azure -> Red Hat integration. The challenge is the link-or-create logic which I perceived to be something that would be way out on the timeline for BZ dev team. 

Jeff Fearn: I think automating the mapping would be quite hard, but just presenting the user with a page to manually map accounts is not so hard. We'd just add an extra column to the user table to keep the mapping in so they only have to do that once. With that in place we can then do the same for Fedora accounts and make them happy as well.

Muhammad, Jeff - what do you think it would take to get this into BZ in a generic, upstream-friendly way? This would be a huge win for Red Hat.

Jeff Fearn: The challenge here is that the current upstream approach to authentication is to do a fall back model, but we won't do that as IMO it's just not a scale-able approach.
e.g. imagine if we support SAML and OAuth and OpenID and BZ native and when you logged in it tried each of those in turn until one worked.
That being said I think we can do it in an extension and then open source that and offer it to upstream as well, some times they do surprise us (Jeff Fearn).

Muhammad via email to Pushpa & Jeff: Due to limited human resources available for BZ development and keeping the current BZ backlog in consideration, I'm hopeful we will be able to invest time in SAML work sometime early next year.

FYI I have not done the select existing account with a different email address. That has been split in to Bug 1351859. We may not get that done for the beta given resource constraints.

We don't have access to a variety of test accounts to be able to test different user configurations, so the code has only been tested on a single Red Hat account on the External IDP.

FWIW I'm loving be able to login to the devel box by having it use my keberos ticket.

(In reply to Jeff Fearn from comment #9)
> FYI I have not done the select existing account with a different email
> address. That has been split in to Bug 1351859. We may not get that done for
> the beta given resource constraints.
> 
> We don't have access to a variety of test accounts to be able to test
> different user configurations, so the code has only been tested on a single
> Red Hat account on the External IDP.
> 
> FWIW I'm loving be able to login to the devel box by having it use my
> keberos ticket.

Brilliant. Can you list the devel instance here so some of us can test? This will result in a second account for me, I would imagine, since my BZ is cbredesen and my kerberos is the awkwardly retro truncaed 'cbredese'.

Thanks for doing this!

Works nicely!!! Thanks for this.

Is there a plan to reconcile the account diffs before rolling out proper?

(In reply to Chris Bredesen from comment #12)
> Works nicely!!! Thanks for this.
> 
> Is there a plan to reconcile the account diffs before rolling out proper?

Hi Chris,  Bug 1351859 is for allowing people to select a "non-matching" accounts.

Hope to get it done before the beta, but at this stage I can't guarantee it. We will probably need to go through the process of getting access to the mx LDAP records, so we can audit the relationships and make sure people actually own the alias they are claiming.

Tested on QA environment(5.0.3-rh6)
Result: Fail
Steps:
1.Click the link 'Red Hat Account' in the login dialog box
==>Parsing of the IDP's metadata failed: verify: unable to get local issuer certificate at /usr/share/perl5/vendor_perl/Net/SAML2/IdP.pm line 170

Fixed server configuration.

Tested on QA environment(5.0.3-rh8)
Result: Pass
Steps:
1.Could login with Red Hat Account(portal)