OK, just to make sure I am getting the right ones - I assume you would want the main portal handler logs of my session and then the remote handler (REST Client) logs?
If so, I will have to do this on some off hours as our traffic is very high during the day.
Yes, sorry for mixing up the terminologies.
Sorry for the delay. I can't find it on the Portal side, other than in real_password
Version: %2.0.16
Platform: (Nginx) | Docker
An application that is protected via a REST LLNG Handler and are passing headers to the application like so:
uid
as REMOTE_USER
_password
REMOTE_PASSWORD
When using Persistent Connections we have found the _password variable is not sent to the Remote LLNG Handler anymore after our initial session timeout (86400 seconds) and sends a blank REMOTE_PASSWORD
header to the protected application.
Simple system with Portal, Handler, and Manager all on one host, and remote handlers that are connected via REST (previously SOAP) either per service or for each physical machine. Postgresql storage for LLNG Portal, and filesystem storage for REST.
graph TD
LLNGPORTAL(Portal Server) -->LLNGHANDLER(LLNG Remote Handler REST) -->APP(Application)
LLNGHANDLER-->LLNGPORTAL
Version: %2.0.16
Platform: (Nginx) | Docker
An application that is protected via a REST LLNG Handler and are passing headers to the application like so:
uid
as REMOTE_USER
_password
REMOTE_PASSWORD
Works fine - with the exception of impersonation/context switching, but that is another issue that cannot be resolved.
When using MFA (We have tested with Webauthn) we have found the _password variable is not sent to the Remote LLNG Handler anymore and sends a blank REMOTE_PASSWORD
header to the protected application.
Simple system with Portal, Handler, and Manager all on one host, and remote handlers that are connected via REST (previously SOAP) either per service or for each physical machine. Postgresql storage for LLNG Portal, and filesystem storage for REST.
graph TD
LLNGPORTAL(Portal Server) -->LLNGHANDLER(LLNG Remote Handler REST) -->APP(Application)
LLNGHANDLER-->LLNGPORTAL
I will try. Before I went to bed last night I thought about this more and realized I didn't give enough details:
Alpine 3.17
Perl 5.34.1
Postgres Backend Session Handler along with Rest
Nginx as frontend webserver
I'm going to sample a handful of people who are far better at doing step by step troubleshooting and report back. I had heard this happening but did not experience it myself until yesterday.
With regards to the cache, if this indeed is the problem, is there a way to alleviate this? Would it be similar to using multiple handlers and having one of them only have the current information until the other refresh similar to when saving options in Manager?
Version: 2.15.1
Platform: Nginx (tiredofit/docker-lemonldap -- My image)
After registering with a Fido Device (oddly enough I don't get confirmation when I do, and can only see it back at 2fa Manager) I now have a Fido key registered to me. When I try to remove it, I am presented with a JS popup "This operation cannot be undone" and select Unregister. It removes from the screen, but upon page reload, the key reappears.
2022-12-14 10:08:08 | LLNG[2717]: [debug] daveconroy request to delete webauthn2f device
2022-12-14 10:08:08 | LLNG[2717]: [debug] Impersonation plugin is enabled
2022-12-14 10:08:08 | LLNG[2717]: [debug] ContextSwitching plugin is enabled
2022-12-14 10:08:08 | LLNG[2717]: [debug] daveconroy is allowed to update 2FA
2022-12-14 10:08:08 | LLNG[2717]: [debug] Deleted 2F Device: { type => WebAuthn, epoch => 1670956099 }
2022-12-14 10:08:08 | LLNG[2717]: [debug] Found 'whatToTrace' -> daveconroy
2022-12-14 10:08:08 | LLNG[2717]: [debug] Update daveconroy persistent session
2022-12-14 10:08:08 | LLNG[2717]: [debug] Update session MASKED
2022-12-14 10:08:08 | LLNG[2717]: [debug] Update sessionInfo _2fDevices
2022-12-14 10:08:08 | LLNG[2717]: [debug] Dump: $VAR1 = '[]';
From manager, the key can be removed.
(one of my junior engineers wrote this up and I offered to send it in - it seems this is happening more and more with our instance and I'm eager to understand if there is something that hasn't been discovered as a bug yet)
I am experiencing an issue with SAML. The issue arises only with some SPs and has been challenging to pin-point.
I am running a fairly standard implementation of LLNG (LDAP Authentication, SAML2 IDP and OIDC RP), version 2.0.14, with LaSSO v2.8.0. I also tested the error with different LaSSO versions. I have also tested with 2.6.1
, 2.6.1.3
, and 2.7.0
.
Note: in the following logs, I've fuzzed our domain and the SP name.
It looks like the service provider metadata is not being added correctly.
2022-04-12 07:16:50 | LLNG[21926]: [debug] Lasso error [ critical ]: 2022-04-12 07:16:50 (server.c/:76) Failed to add new provider.
2022-04-12 07:16:50 | LLNG[21926]: [error] Lasso error code -202: Failed to add new provider.
2022-04-12 07:16:50 | LLNG[21926]: [error] Fail to use SP organization.service.com Metadata
I've confirmed that the assertion/issuer matches the entityID from the SP metadata:
The decoded SAML
<AuthnRequest ID="samlrequest_64136f3769f542f6acdf64ddeb49ff7a" Version="2.0" IssueInstant="2022-04-12T17:56:04.3168995Z" AssertionConsumerServiceURL="https://organization.service.com/xxx/xx/auth/login/samlLogin.xxx" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://0b2076f0-4054-4937-98a5-08199ed2fee5.tenants.service.com/samlLogin</Issuer>
</AuthnRequest>
The Request vvv
https://0b2076f0-4054-4937-98a5-08199ed2fee5.tenants.service.com/samlLogin
https://0b2076f0-4054-4937-98a5-08199ed2fee5.tenants.service.com/samlLogin
The Metadata ^^^
In the LLNG logs, I find:
2022-04-12 10:56:15 | LLNG[21926]: [debug] HTTP-REDIRECT: SAML Request SAMLRequest=jZE9b4MwEIb3Sv0PyDvYgIHYgkhRu0RKl6Tt0KUycCZIxqY%2bU%2fXnlyRq1bHbfeiVnueu3i3hbI%2fwsQCGaP%2fYEFST8bf%2bveRpXuq8KoUueKZL1fW65H0PLRdaV4pEr%2bBxdLYhWcJItEdcYG8xKBvWEcuymPE4zZ7TShalZDzJ03IjRPFGoh0i%2bLBmH5zFZQJ%2fAv85dvByPDTkHMKMklIEo3vAcbCJs2a0YEB5O9qh7ZLOTbTPDDUzVasENW4YLb3gHy5Vsu5I9DUZiw1ZvJVO4YjSqglQhk6edk8HuVLL2bvgOmfI9v4uiuqrg%2f9PUP0YkO0PL2szVpWaxZwVPOYir2KxUUXMNqkQ0GcaoEgC2PU%2bmLR%2bHM4BZ9XBVeYXvaY3iBWopn8ftP0G
2022-04-12 10:56:15 | LLNG[21926]: [debug] Lasso error [ debug ]: 2022-04-12 10:56:15 (xml.c/:1492) lasso_node_impl_init_from_xml<AuthnRequest>
2022-04-12 10:56:15 | LLNG[21926]: [debug] Lasso error [ debug ]: 2022-04-12 10:56:15 (xml.c/:1461) Matching node Issuer vs snippet Issuer: SUCCESS namespace URIs match
2022-04-12 10:56:15 | LLNG[21926]: [debug] Lasso error [ debug ]: 2022-04-12 10:56:15 (xml.c/:2577) Processing node 'Issuer' with type 'LassoSaml2NameID'
2022-04-12 10:56:15 | LLNG[21926]: [debug] Lasso error [ debug ]: 2022-04-12 10:56:15 (xml.c/:1492) lasso_node_impl_init_from_xml <Issuer>
2022-04-12 10:56:15 | LLNG[21926]: [debug] Lasso error [ debug ]: 2022-04-12 10:56:15 (xml.c/:1901) lasso_node_impl_init_from_xml </Issuer> rc=0
2022-04-12 10:56:15 | LLNG[21926]: [debug] Lasso error [ debug ]: 2022-04-12 10:56:15 (xml.c/:1901) lasso_node_impl_init_from_xml </AuthnRequest> rc=0
2022-04-12 10:56:15 | LLNG[21926]: [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().
2022-04-12 10:56:15 | LLNG[21926]: [error] SSO: Fail to process authentication request
2022-04-12 10:56:15 | LLNG[21926]: [debug] Returned error: 51 (PE_SAML_SSO_ERROR)
2022-04-12 10:56:15 | LLNG[21926]: [debug] Skin returned: error
2022-04-12 10:56:15 | LLNG[21926]: [debug] Calling sendHtml with template error
The LaSSO documentation for error -201 suggests that the provider identifier is not being added as expected. LaSSO documentation
In your open issues, I found #2066. But our metadata does use the SPSSODescriptor rather than a IdP descriptor. Our SP is no using ADFS and WS-FED. So this is looking like a different, but perhaps related issue?
The error SSO: Fail to process authentication request appears here: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/v2.0/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Issuer/SAML.pm