-
Suggestion
-
Resolution: Unresolved
-
Low
-
None
-
None
-
None
-
None
Currently, you must have your SSO attribute be username in order to pull in the username. If the username is set to example@example.com, but the username in Bitbucket is example, it cannot be synced receiving the following:
ERROR [http-nio-7101-exec-6] @NA67I8x1222x1487x0 11vbk2y 100.127.66.23,100.64.18.192,127.0.0.1 "POST /plugins/servlet/samlconsumer HTTP/1.1" c.a.p.a.i.w.f.ErrorHandlingFilter Received SAML assertion for user example@example.com, but the user doesn't exist in the product com.atlassian.plugins.authentication.impl.web.usercontext.AuthenticationFailedException: Received SAML assertion for user example@example.com, but the user doesn't exist in the product
Example: A user has the email example@example.com and username TEST1 in our apps. If the IdP has the user with email example@example.com but there is no reference to TEST1 at all in the attributes, there's no way to tell our apps to use the email field rather than the username field for a match with the IdP.
The suggestions would be to allow Atlassian apps to be configurable to change from the default username to other fields such as email to meet scenarios like this example.
[SAMLDC-43] Allow remapping of username attribute in SSO
| Remote Link | Original: This issue links to "KRAK-1156 (JIRA Server)" [ 349677 ] | New: This issue links to "KRAK-1156 (JIRA Server (Bulldog))" [ 349677 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 823354 ] |
| Workflow | Original: SAMLDC Workflow v2 [ 2414550 ] | New: JAC Suggestion Workflow 3 [ 4271311 ] |
| Status | Original: Open [ 1 ] | New: Gathering Interest [ 11772 ] |
| Issue Type | Original: New Feature [ 2 ] | New: Suggestion [ 10000 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 448456 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 424119 ] |
I agree with you Jean.
I would like to have a new Field as"Authentication Attribute" with Email OR Username as options in the list
Administrator could choose the attribute to map (in user Directory). The attribute would be matched against the NameID or the differing user ID attribute below.
Thank you.
Best regards,
Sébastien Lucchini.
| Description |
Original:
Currently, you must have your SSO attribute be username in order to pull in the username. If the username is set to example@example.com, but the username in Bitbucket is example, it cannot be synced receiving the following:
{code} ERROR [http-nio-7101-exec-6] @NA67I8x1222x1487x0 11vbk2y 100.127.66.23,100.64.18.192,127.0.0.1 "POST /plugins/servlet/samlconsumer HTTP/1.1" c.a.p.a.i.w.f.ErrorHandlingFilter Received SAML assertion for user example@example.com, but the user doesn't exist in the product com.atlassian.plugins.authentication.impl.web.usercontext.AuthenticationFailedException: Received SAML assertion for user example@example.com, but the user doesn't exist in the product {code} Allowing for you to tell SAML what to look for to map to the username in Bitbucket, would be the solution for this as it would allow admins to more easily work around previous settings and configurations. |
New:
Currently, you must have your SSO attribute be username in order to pull in the username. If the username is set to example@example.com, but the username in Bitbucket is example, it cannot be synced receiving the following:
{code} ERROR [http-nio-7101-exec-6] @NA67I8x1222x1487x0 11vbk2y 100.127.66.23,100.64.18.192,127.0.0.1 "POST /plugins/servlet/samlconsumer HTTP/1.1" c.a.p.a.i.w.f.ErrorHandlingFilter Received SAML assertion for user example@example.com, but the user doesn't exist in the product com.atlassian.plugins.authentication.impl.web.usercontext.AuthenticationFailedException: Received SAML assertion for user example@example.com, but the user doesn't exist in the product {code} *Example*: A user has the email example@example.com and username TEST1 in our apps. If the IdP has the user with email example@example.com but there is no reference to TEST1 at all in the attributes, there's no way to tell our apps to use the *email* field rather than the *username* field for a match with the IdP. The suggestions would be to allow Atlassian apps to be configurable to change from the default *username* to other fields such as *email* to meet scenarios like this example. |
While there is no UI for it, it is possible to configure the SAML integration to use an assertion attribute, rather than the NameID element for the username.
The steps necessary are described here.
this effects us significantly