Über dieses Feld kann man das Zertfikat einfügen
Hier wäre das Zertifikat als Text einzusetzen.
Etwa so :
-----BEGIN CERTIFICATE-----
FHRaeWaszcfacvhwdagd64ucy6cv4aca7f8a
yci7a68w7goq08ezqvheohuoz
…undsoweiter
-----END CERTIFICATE-----
Das Zertifikat sollte natürlich auch für die entityID konfigurerte Domain ausgegeben sein.
Das Zertifikat sollte natürlich auch für die entityID konfigurerte Domain ausgegeben sein.
es geht mir nicht um das Zertifikat, sondern um die 2 Felder Login URL und SLO URL
ist es gedacht da die URLs des SP oder des IdP einzutragen?
braucht SuiteCRM bestimmte SAML Attribute?
ist es gedacht da die URLs des SP oder des IdP einzutragen?..
Vermutlich, Mal probieren und im XML der Metadaten nachschauen.
SP ist Suitecrm. Der Ablauf ist etwa wie folgt:
Browserclient ohne gültige Anmeldung geht zum SP
SP antwortet mit Redirect zum IDP,
IDP redirectet zu ADFS (in ihrem Fall zu inwebo)
Inwebo redirectet wieder zu IDP
IDP prüft die von inwebo erstellte saml assertion und rediected mit gültiger Anmeldung zum Service (SuiteCRM).
So ist zumindest der Standardablauf bei SAML HTTP-redirection. Im Content jedes dieser Requests sollte die jeweilige SAML-assertion sichtbar sein, weil in ihrer Umgebung (settings.pgp) keine encryption geschaltet ist. Im Browser sollte das mit F12 verfolgbar sein.
Wollen sie Single signon mit inwebo machen und dabei die Identitäten aus einer Windows Domainsitzung verwenden?
Guten Morgen,
inWebo ist IdP. Nein kein SSO. SuiteCRM User sind lokale User (kein AD/LDAP etc.)
der Aufruf bei SuiteCRM lautet ja https://url-suitecrm/index.php?action=Login&module=Users
nach meiner Kenntnis ist das “&” nicht zulässig in einer SAML 2 Assertion
SuiteCRM loggt den User nach erfolgreicher Authentication direkt wieder aus 
wie sieht im log warum?
mein XML meta sieht so aus:
<md:EntityDescriptor xmlns:md=“urn:oasis:names:tc:SAML:2.0:metadata” validUntil=“2021-04-21T11:48:22Z” cacheDuration=“PT604800S” entityID=“https://192.168.238.171:8080/index.php?action=Login&module=Users”>
<md:SPSSODescriptor AuthnRequestsSigned=“false” WantAssertionsSigned=“false” protocolSupportEnumeration=“urn:oasis:names:tc:SAML:2.0:protocol”>
<md:SingleLogoutService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=“https://192.168.238.171:8080/index.php?action=Login&module=Users”/>
md:NameIDFormaturn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:AssertionConsumerService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=“https://192.168.238.171:8080/index.php?action=Login&module=Users” index=“1”/>
<md:AttributeConsumingService index=“1”>
<md:ServiceName xml:lang=“en”>SuiteCRM</md:ServiceName>
<md:ServiceDescription xml:lang=“en”>SuiteCRM</md:ServiceDescription>
<md:RequestedAttribute Name="" NameFormat="" FriendlyName="" isRequired=“false”/>
</md:AttributeConsumingService>
</md:SPSSODescriptor>
</md:EntityDescriptor>
Haben sie denn in einem anderen Anwendungsfall (Serviceprovider) den inwebo bereits erfolgreich zur Authentifizierung genutzt?
Haben sie denn in einem anderen Anwendungsfall (Serviceprovider) den inwebo bereits erfolgreich zur Authentifizierung genutzt?
ja
Ich kenne das Spiel bisher nur zwischen ADFS und Oracle Oim. Da hatte ich noch nie & in den Uri. Grundsätzlich ist das aber ein in Uri erlaubt es Zeichen…Vielleicht Mal escapen. Auffällig ist, dass wir in den Metadaten zum IDP kein Binding für den sso-Service (SingleSignOnService) finden, sondern nur den logout.
für das “&” habe einen Workaround gefunden
Special characters may cause signed SAML assertion to fail (f5.com)
aber das bringt mich nicht wirklich weiter
Wie sehen denn jetzt die Assertions aus, welche über den Browser laufen?
Wie sehen denn jetzt die Assertions aus, welche über den Browser laufen?
sieht so aus:
”<md:AssertionConsumerService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location="https://192.168.238.171:8080//index.php?action=Login&module=Users” index=“1”/>”
der Browser verschluckt das:
