Konnect w/SAML2
-
Me again. Apologies if this is in the Core section and should actually be in meet, but opted for here since Konnect is mentioned in the Core manual.
I’m taking a look at Konnect to get a better handle on how Single Sign on works. I’m able to get it to work against the KC backend, but noted inside the sample identifier.yaml that there is SAML2 support.
Am I correct in thinking that I could have Konnect whenever it is called authenticate against my SAML2 IDP Provider (with it exporting a
uid
value) allowing my central authentication system to have to take the place of logging in yet again to use Konnect services?I did try to enable the SAML2 component in the identifier configuration and Konnect states that it has been loaded.
INFO[0000] authority is now ready id=llng type=saml2
and forwards to my own IDP, yet throws errors because it has not been setup on the IDP as a Service Provider.I’m not super up to speed on authentication but with setting up other SAML2 entities I have required metadata on both the IDP and SP end. I’ve tried to look in the Konnect code to see if there is a path that I can use for getting this metadata with no such luck.
The closest I can find is
curl 127.0.0.1:8777/konnect/v1/identifier/saml2/metadata
however I get a 404 response.Any advice? I’ll report my findings and write up a tutorial for others to benefit from if I can get this going.
I am starting it on the command line as such for now:
/usr/libexec/kopano/konnectd serve --identifier-client-path=/usr/share/kopano-konnect/identifier-webapp --identifier-registration-conf=/etc/kopano/identifier-registration.yaml.in --iss=https://konnect.example.com dummy
^^ Note I have also tried
kc
as the backendMy identifier config looks as such:
--- - id: llng name: llng entity_id: kopano-konnect authority_type: saml2 default: yes trusted: yes discover: yes metadata_endpoint: https://auth.example.com/saml/metadata identity_claim_name: uid identity_alias_required: false end_session_enabled: true
-
@tiredofit said in Konnect w/SAML2:
The closest I can find is curl 127.0.0.1:8777/konnect/v1/identifier/saml2/metadata however I get a 404 response.
Any advice? I’ll report my findings and write up a tutorial for others to benefit from if I can get this going.SAML2 support is experimental and thus we have not yet added any documentation for it.
Having that said, the URL you are looking for is
http://127.0.0.1:8777/signin/v1/identifier/saml2/metadata
.Konnect offers SAML2 endpoints for ACS and SLO (Exact URLs should be in the metadata document).
The saml2 metadata document is only available when the identifier has correctly configured and initialized with the SAML2 IdP.
Please let me know how it goes.
Would you please also share what SAML2 IdP do you use? (Software, Version, etc…).
-
Thanks for the reply. I was able to extract the Metadata when I switched back to
kc
mode.
I am using LLNG latest stable version 2.0.9. It’s a rather elegant solution that I’ve used in an Organization for many years.Now the bad part. I wasn’t able to authenticate - LLNG relies on LASSO for it’s SAML authentication and spat out the following errors:
[debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1492) lasso_node_impl_init_from_xml <AuthnRequest> [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1461) Matching node Issuer vs snippet Issuer: SUCCESS namespace URIs match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:2577) Processing node 'Issuer' with type 'LassoSaml2NameID' [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1492) lasso_node_impl_init_from_xml <Issuer> [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1901) lasso_node_impl_init_from_xml </Issuer> rc=0 [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1451) Matching node NameIDPolicy vs snippet Signature: FAILURE names don't match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1451) Matching node NameIDPolicy vs snippet Extensions: FAILURE names don't match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1451) Matching node NameIDPolicy vs snippet PrivateKeyFile: FAILURE names don't match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1451) Matching node NameIDPolicy vs snippet CertificateFile: FAILURE names don't match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1451) Matching node NameIDPolicy vs snippet Subject: FAILURE names don't match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1456) Matching node NameIDPolicy vs snippet NameIDPolicy: SUCCESS namespace prefixes match [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:2577) Processing node 'NameIDPolicy' with type '(null)' [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:2577) Processing node 'NameIDPolicy' with type 'LassoSamlp2NameIDPolicy' [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1492) lasso_node_impl_init_from_xml <NameIDPolicy> [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1901) lasso_node_impl_init_from_xml </NameIDPolicy> rc=0 [debug] Lasso error [ debug ]: 2020-09-15 11:32:15 (xml.c/:1901) lasso_node_impl_init_from_xml </AuthnRequest> rc=0 [error] Lasso error code -201: The identifier of a provider is unknown to #LassoServer. To register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer(). [error] SSO: Fail to process authentication request [debug] Returned error: 51 (PE_SAML_SSO_ERROR)
Konnect with log-level=debug didn’t output anything.
For what it’s worth I’m doing the following:
Exporting attributes: uid (sending ldap username)
Default Name ID Format: Unspecified (also tried Transient, Persistent, Entity)
Signing the SSO Message from IDP
Not checking SSO Signature from Konnect
Signing SLO message from IDP
Not checking SLO Signature from IDP.I could quickly setup access to an LLNG development server tied to a few sample logins if you would like to see how LLNG looks behind the scenes. I also have a Docker Image that is fairly easy to setup.
-
Those error messages seem to indicate a problem in the SOAP IdP.
-
I have made a bit more progress. I can successfully authenticate against the IDP and pass my UID across. SAML Inspector shows that it has succeeded and I see the value.
Problem is that it just keeps looping over and over again authenticating against Konnect with little logs as to understand, what could be happening.
PS - NameID Transient got me to where I am.
Konnectd Debug on successful authorization thrugh IDP:
time="2020-09-18T19:44:46-07:00" level=debug msg="saml2 attributeStatement" FriendlyName=uid Name=uid NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Values="[username]" time="2020-09-18T19:44:46-07:00" level=debug msg="saml2 authnStatement" SessionIndex=e3c06f66c34b9f126f804dbeac31a26736077e8689fa3d8bd1f229fe2437215d SessionNotOnOrAfter="2020-09-19 10:09:32 +0000 UTC"
SAML Response decoded is sending to
https://my.host/signin/v1/identifier/saml2/acs
but continues to loop.Edit - When I head back to Meet I am thrown to the login screen, but a refresh sends me into the video screen “<site>/r/call”