757702 - integrate bmo with service-now

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Extensions, defect)

Description

[:glob ✱]

add an connector to the push extension to integrate with service-now.
we need to push bug updates to them via their soap api.

only bugs with a particular custom field set will be pushed (or we may use the see-also field, depending on its appropriateness).

Comment 1

[:glob ✱]

(In reply to Byron Jones ‹:glob› from comment #0)
> only bugs with a particular custom field set will be pushed (or we may use
> the see-also field, depending on its appropriateness).

we ended up pushing bugs in the "Server Operations: Desktop Issues" component only.

Comment 2

[:glob ✱]

we'll need input from the security team prior to go-live; putting this on their radar.

the security review for push itself is bug 599979.

Comment 3

[David Chan [:dchan]]

The code looks sane from reading it, though I have some questions on the purpose / workflow of this connector.

When desktop bugs are filed or when attachments are filed for those bugs, the connector will connect to services-now and POST a json blob. Also there seems to be an e-mail that is sent.

1. What exactly is the services-now component?
2. Who will receive the bug data? I noticed that the code does a ldap lookup based on bmo logins. Does it mail everyone on the CC? people in the desktop group? other?
3. Can we trust the returned data?
    eval {
        $result_data = from_json($result->content);
    };
4. Do we care about URIs in the form of
https://foobar/blah.service-now.com/
                $_[0] =~ m#^https://[^\.]+\.service-now\.com\/#
                    || die "Invalid Service Now JSON URL\n";


Aside from the above, the permissions checking, component / keyword checking looks good.

Comment 4

[:glob ✱]

(In reply to David Chan [:dchan] from comment #3)
> When desktop bugs are filed or when attachments are filed for those bugs,
> the connector will connect to services-now and POST a json blob. Also there
> seems to be an e-mail that is sent.

oops, the _build_email method is from an implementation against the original specifications and is not actually called.  i'll remove it.

> 1. What exactly is the services-now component?

  mozilla.org :: Server Operations: Desktop Issues

it's defined by the SEND_COMPONENTS constant near the top of the file.

> 2. Who will receive the bug data? I noticed that the code does a ldap lookup
> based on bmo logins. Does it mail everyone on the CC? people in the desktop
> group? other?

it doesn't send an email - the json message is sent directly to service-now via their json api.  this happens at https://github.com/globau/bugzilla-push/blob/master/Push/lib/Connector/ServiceNow.pm#L237

the ldap lookup is there because accounts in service-now use ldap, while bmo does not.  we do an ldap lookup to provide service-now with both the bmo and ldap account in our json data.

> 3. Can we trust the returned data?
>     eval {
>         $result_data = from_json($result->content);
>     };
>     if ($@) {
>         die sprintf("Failed to connect to %s://%s/: %s\n", $scheme, $host, $@);
>     }

this is how you write try/catch blocks in perl.
the response isn't actually evaluated.

> 4. Do we care about URIs in the form of
> https://foobar/blah.service-now.com/
>                 $_[0] =~ m#^https://[^\.]+\.service-now\.com\/#
>                     || die "Invalid Service Now JSON URL\n";

this verification code is executed when a bugzilla administrator alters the setting, so it's mostly there to catch obvious mistakes.  i'll add / into that character class.

Comment 5

[David Chan [:dchan]]

Thanks for the clarifications Byron!

Assuming the below is true, then we can close out the security review portion of the bug.

Workflow
1. User files a bug / creates attachment under mozilla.org :: Server Operations: Desktop Issues
2. Push connector looks up the users LDAP login based on their BMO login (retrieved from bug data). This is only done for emails that end in mozilla.(org|com)
3. Push connector makes a POST to service-now JSON api with contents of the bug and the LDAP login of the bug creator / modifier. This is ignored for bugs created/modified by the service-now BMO account. The communication uses basic-auth for authentication and happens over SSL?

Comment 6

[:glob ✱]

your workflow is close; i'll detail it end-to-end here (sorry, i should have done this earlier).

1. triggered by any action relating to bugs in the 'Server Operations: Desktop Issues' component (new bugs, attachments, comments, bug updates, moving bugs into the component, ...)

2. the bug/attachment/comment is serialised to json and inserted into a 'push' table (part of the bugzilla database)

3. a daemon polls the table, pops messages and passes them to the appropriate connector class (service-now in this case)

4. the connector augments the json data by attempting to match the bmo login to a moco ldap account.  this happens for every user associated with the bug, regardless of the domain.  if a bmo->ldap mapping isn't found, the message is still sent.  (note: there's a cache to avoid hammering ldap).

5. the connector calls service-now's json api over ssl using basic-auth with the augmented json message as payload. logic on service-now deals with mapping fields and values to service-now and updating the ticket.

Comment 7

[David Chan [:dchan]]

Thanks. I'm going to mark the sec-review as completed.

Comment 8

[:glob ✱]

we have word from desktop that this integration is no longer required.