Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-1

Support email aliases on LDAP/SAML synched users

    • Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      A user that is synched from LDAP (via SAML say) has a single canonical address.

      However they often have multiple email aliases.  eg

      bradbaker@foo, bbaker@foo and brad@foo all represent the canonical user brad.baker@foo

      Today there is no email aliases stored.

      This is problematic for JIRA Server Desk say on an incoming email ticket because bbaker@foo will not match and existing user and hence we will try to create a new user and onboard them into the system or reject the email ticket outright because we dont know the user.

       

      IM needs the ability to store email aliases so we can look them up and find the right person to associate the ticket with.

       

       

            [ACCESS-1] Support email aliases on LDAP/SAML synched users

            mfitzbaxter - in the JSD case its very much about having the ability to have a list of email aliases hang off a user and then be able to query that at incoming email processing time.  It less about them being able to login via those email aliases.  It allows us to create tickets against a "known user"correctly  more times than not.

             

            Today we store (logically)

               GUUID userId

               String displayName

               String emailAddress

             

            In the future I see something like that PLUSa list of aliases

              List<Sttring> emailAliases

            I dont think we should (we could but do we have to??) make the email aliases globally unique.

            And then have an API to query by email aliases.  During our incoming email processing we would take the email address on the email and then hit the Identity API with "give me the user with this email address including aliases".  If it can resolve that back to a cannonical user then great.  If it cant, then we would go into a error handling case.

             

            The 2 error paths I see it does not exist at all (easy) or yes but there are two people with that email address alias.  Either way 95% of the time we would be creating tickets in terms of the right person and only some of the time would we be having to do error cases.

             

            Without email aliases, we are going to get it wrong 100% of the time some one uses an alias on an incoming email.

            ɹǝʞɐq pɐɹq added a comment - mfitzbaxter - in the JSD case its very much about having the ability to have a list of email aliases hang off a user and then be able to query that at incoming email processing time.  It less about them being able to login via those email aliases.  It allows us to create tickets against a "known user"correctly  more times than not.   Today we store (logically)    GUUID userId    String displayName    String emailAddress   In the future I see something like that PLUSa list of aliases   List<Sttring> emailAliases I dont think we should (we could but do we have to??) make the email aliases globally unique. And then have an API to query by email aliases.  During our incoming email processing we would take the email address on the email and then hit the Identity API with "give me the user with this email address including aliases".  If it can resolve that back to a cannonical user then great.  If it cant, then we would go into a error handling case.   The 2 error paths I see it does not exist at all (easy) or yes but there are two people with that email address alias.  Either way 95% of the time we would be creating tickets in terms of the right person and only some of the time would we be having to do error cases.   Without email aliases, we are going to get it wrong 100% of the time some one uses an alias on an incoming email.

              Unassigned Unassigned
              bbaker ɹǝʞɐq pɐɹq
              Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: