In order for us to analyse and understand your problem, we need at least the following information up-front:
Have you followed the following instructions?
Which vendor (or product) are you using (octa, azure, centrica, other (which one)?)
Team ID (looks like eg.
2e9a9c9c-6f83-11eb-a118-3342c6f16f4e, can be found in the team management app)
User ID of the account that has the problem (alternatively: handle, email address)
What do you expect to happen?
e.g.: “I enter login code, authenticate successfully against IdP, get redirected, and see the wire landing page.”
What does happen instead?
Copy the text into your report where applicable in addition to screenshots (for automatic processing).
e.g.: “instead of being logged into wire, I see the following error page: …”
Screenshots of the Configuration (both SAML and SCIM, as applicable), including, but not limited to:
If you are using SAML: SAML IdP metadata file
If you are using SCIM for provisioning: Which attributes in the User schema are mapped? How?
If you have successfully authenticated on your IdP and are redirected into wire, and then see a white page with an error message that contains a lot of machine-readable info: copy the full message to the clipboard and insert it into your report. We do not log this information for privacy reasons, but we can use it to investigate your problem. (Hint, if you want to investigate yourself: it’s base64 encoded!)
notes for wire support / development
Not officially supported IdP vendors may work out of the box, as we are requiring a minimum amount of SAML features.
If there are problems: collect the metadata xml and an authentication response xml (either from the browser http logs via a more technically savvy customer; or from the “white page with an error” mentioned above.
https://github.com/wireapp/saml2-web-sso supports writing unit vendor compatibility tests against that response value. Once that test passes, it should all work fine.
Yes. Scim is a technology for onboarding alternative to the team management app, and can produce both user accounts authenticated via SAML or via email and password. (Phone may or may not work, but is not officially supported.)
How does it work? Make sure your team has no SAML IdPs registered. Set up your SCIM peer to provision users with valid email addresses as
externalIds. Newly provisioned users will be created in status
PendingInvitation, and an invitation email will be sent. From here on out, the flow is exactly the same as if you had added the user to your team in the team management app.
support for the
emailsfield in the scim user record (so you can choose non-email
flexible mapping between any number of SAML IdPs and any number of SCIM tokens in team management.
Yes, but this is not recommended. User (de-)provisioning requires more manual work without SCIM, and some of the account information cannot be provisioned at all via SAML.
Most SAML IdP products allow you to register arbitrary many apps for arbitrary many teams, by using a different entity Id for each app/team. This is currently supported out of the box.
If you don’t have this option, i.e. you need to serve two teams with an IdP that has only one entity ID, please keep reading and/or contact customer support.
The long answer
Some SAML IdP vendors do not allow to set up fresh entity IDs (issuers) for fresh apps; instead, all apps controlled by the IdP are receiving SAML credentials from the same issuer.
In the past, wire has used a tuple of IdP issuer and ‘NameID’
(Haskell type ‘UserRef’) to uniquely identity users (tables
In order to allow one IdP to serve more than one team, this has been
changed: we now allow to identify an IdP by a combination of
entityID/issuer and wire
TeamId. The necessary tweaks to the
protocol are listed here.
This extension is currently (as of 2023-02-03) not supported by the team management app. If you need this, please contact customer support.
what you need to know when operating a team or an instance
No instance-level configuration is required.
If your IdP supports different entityID / issuer for different apps, you don’t need to change anything.
If your IdP does not support different entityID / issuer for different apps, keep reading. At the time of writing this section, there is no support for multi-team IdP issuers in the team management app, so you have two options: (1) use the rest API directly; or (2) contact our customer support and send them the link to this section.
If you feel up to calling the rest API, try the following:
Use the above end-point
GET /sso/metadata/:tidwith your
TeamIdfor pulling the SP metadata.
POST /identity-provider, make sure to add
?api_version=v1or no omission of the query param both invoke the old behavior.)
NB: Neither version of the API allows you to provision a user with the same Issuer and same NameID. The pair of Issuer and NameID must always be globally unique.
API changes in even more detail
New query param
POST /identity-providers. The version is stored in
spar.idptogether with the rest of the IdP setup, and is used by
GET /sso/initiate-login(see below).
GET /sso/initiate-loginsends audience based on api_version stored in
spar.idp: for v1, the audience is
/sso/finalize-login; for v2, it’s
POST /sso/finalize-login/:tidthat behaves indistinguishable from
POST /sso/finalize-login, except when more than one IdP with the same issuer, but different teams are registered. In that case, this end-point can process the credentials by discriminating on the
POST /sso/finalize-login/remains unchanged.
GET /sso/metadata/:tidreturns the same SP metadata as
GET /sso/metadata, with the exception that it lists
"/sso/finalize-login/:tid"as the path of the
GET /sso/metadataremains unchanged, and still returns the old SP metadata, without the
TeamIdin the paths.
database schema changes
Yes, you can, by updating the user via SCIM. (If you use SAML without SCIM, there is a way in theory, but there are no plans to implement it.)
No, this is not implemented. But the team admin can remove all IdPs, which will effectively disable all SAML logins.
There is nothing to be done here. There is no internet traffic between your SAML IdP and the wire service. All communication happens via the browser or app.
The user who creates the team cannot be authenticated via SSO. There is fundamentally no easy way around that: we need somebody to give us the IdP credentials, and we need to trust that somebody. For now, that’s the team owner with their password.
(It is also unwise to bind that owner to SAML once it’s installed. If there is ever any issue with SAML authentication that can only be resolved by updating the IdP metadata in the team management app, the owner must still have a way to authenticate in order to do that.)
There is a good workaround, though: you can create a team with user A and use A for registering the IdP. All the users for everyday use and maintenance of the team, including admins and owners, can then be created via SSO (either IdP or SCIM). The original user A is only ever used for IdP registration and upgrade of IdP-authenticated owners / admins.
In practice, user A and some owner authenticated via IdP would then be controlled by the same person, probably.
Here is an example that works. Much of this beyond the subject’s NameID is required by the SAML standard. If you can find a more minimal example that still works, we’d be love to take a look.
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="..." IssueInstant="..." Version="2.0"> <saml:Issuer>...</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#..."> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">...</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData Address="..." InResponseTo="..." NotOnOrAfter="..." Recipient="https://prod-nginz-https.wire.com/sso/finalize-login"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="..." NotOnOrAfter="..."> <saml:AudienceRestriction> <saml:Audience>https://prod-nginz-https.wire.com/sso/finalize-login</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="..." SessionNotOnOrAfter="..."> <saml:SubjectLocality Address="..."/> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion>
Why does the auth response not contain a reference to an auth request? (Also: can i use IdP-initiated login?)
tl;dr: Wire only supports SP-initiated login, where the user selects the auth method from inside the app’s login screen. It does not support IdP-initiated login, where the user enters the app from a list of applications in the IdP UI.
The full story
SAML authentication can be initiated by the IdP (eg., Okta or Azure), or by the SP (Wire).
A user doing IdP-initiated authentication starts from some dashboard in her IdP portal, and selects a button or link to the SP she wants to interact with. The IdP will then refer the user to the SP with the SAML credentials in the redirect request. The user needs to do nothing but wait for the App to start.
In SP-initiated authentication, the user starts off on the login screen of the app or web site of the SP. She selects the IdP she wants to authenticate with, and gets redirected there with an authentication request.
That last part is important: the authentication request contains cryptographic credentials that make some attacks (like machine-in-the-middle attacks for stealing sessions and making users impersonate rogue accounts) hard that were otherwise quite feasible.
Wire therefore only supports SP-initiated login.
Wire only uses the SAML
NameID from the assertion, plus the
information whether authentication and authorization was successful.
Any other information is ignored. In particular, Wire does not
AttributeStatements. For best user experience, use
SCIM for provisioning users (see next section).
If SCIM is not in the picture, the SAML
NameID is used to give the
wire user display name a default value. (The user will be allowed to
change that value later; changing it does NOT affect the
authentication handshake between wire and the IdP.)
If you are provisioning users via SCIM, the following mapping is used in your wire team:
userNameis mapped to wire’s handle. It must be unique accross the entire wire cloud or instance, and consist of the characters
a-z0-9_.-(no capital letters).
displayNameis mapped to wire’s user display name. It must consist of 1-128 unicode characters, and does not need to be unique.
preferredLanguageis mapped to wire’s user locale settings when a locale is not defined for that user. It must consist of an ISO 639-1 language code.
If SAML SSO is used, it is mapped on the SAML
NameID. If it parses as an email, it will have format
If email/password authentication is used, SCIM’s
externalIdis mapped on wire’s email address, and provisioning works like in the team management app with invitation emails.
This means that if you use email/password authentication, you must
map an email address to
externalId on your side. With
displayName, you are more flexible.
All three fields are mandatory.
Also note that the account will be set to
"active": false until the
user has accepted the invitation and activated the account. Please
contact customer support if this causes any issues.
Users may find it awkward to copy and paste the login code into the form. If they are using the webapp, an alternative is to give them the following URL (fill in the login code that you can find in the team management app):
You can technically configure your SAML IdP to create name clashes in wire, ie., to map two (technically) different NameIDs to the same wire user.
How to know you’re safe
This is highly unlikely, since the
distinguishing parts of
NameID that we ignore are generally either
unused or redundant. If you are confident that any two users you have
assigned to the wire app can be distinguished solely by the
NameID content, you’re safe.
If you are using SCIM for user provisioning, this may lead to errors during provisioning of new users (“user already exists”). If you use SAML auto-provisioning, this may lead to unintential account sharing instead of an error.
How to reproduce
If you have users whose combination of
NameID can only be distinguished by casing (upper
vs. lower) or by the
NameID qualifiers (
NameID xml attributes
IdPNameQualifier, …), those users will name
Do not rely on case sensitivity of
NameID, or on
NameID qualifiers for distinguishing user identifiers.
Problem: when logging in using SSO, the user gets redirected to the IdP page. After entering the credentials, IdP successfully authenticates but is stuck at the stage where redirection needs to happen to Wire app.
The console log may mention CSP violations, or declare to refuse to
forward form data to the
Possible cause and fix: Some browsers (chrome is one example) prevent redirects if there is a risk of leaking sensitive form data to the redirect target. In your setup (in particular when you’re using email domain-based redirect from the wire cloud to your on-prem instance), your browser may decide to not trust the wire app with the results of the IdP login procedure. In order to circumvent this issue your IdP needs to be configured to add “wire://*” to the “form-action” CSP value.