I'm a Service Provider, and the SME for the Identity Provider has specified that they require that the SP provide them a certificate different from the standard server certificate.
Every SSO Integration I've accomplished so far has had the IdP provide me with the certificate.
Is a SP able create and provide a separate certificate to the IdP?
Currently, the IdP SME is advising that unless I can provide this, he won't enable Solicited SSO(SP-Initiated SSO).
Related
How do I install a signing certificate in Keycloak when using Keycloak as a Service Provider (SP) that should connect to a (non-Keycloak) Identity Provider (IdP)?
To be more precise, Keycloak should be used as an Identity Broker (as described in the Keycloak documentation) and the communication between the Keycloak SP and the IdP is going to be facilitated via the SAML 2.0 protocol.
The Keycloak documentation contains information on how to install SSL certificates for doing "normal" HTTPS communication e.g. in the browser, but I cannot find anything regarding the installation of signing certificates to be used in the backend-to-backend SAML communication with the IdP. Does anyone know how to do this?
(Maybe only one certificate is installed into Keycloak, i.e. this certificate is used for both SAML communication and other non-SAML Keycloak HTTPS communication?)
How do you see which Certificate is used by your SP for signing/encrypting SAML messages for/to the external IDP?
Go to Identity Providers -> your configured SAML IDP -> Export. The export contains the certificate which is used for signing/encryption. There must be at least one activated signing/encryption config in your IDP, otherwise you will not see a cert in the export
How can I change the Certificate used by my configured IDP?
When creating a realm, keycloak generates a RSA-SHA256 Cert which will by default be used by your configured IDP-Brokering Settings.
Go to Realm Settings -> Keys and you will see this one RS256 (RSA) with the provider (rsa-generated)
If you need another cert, switch to Providers Tab, Add Keystore e.g. rsa. Import your private key and certificate (both as PEM format!)
Back on the overview, disable the rsa-generated provider, your new generated provider should be the only active one with type RS256
If you now check the Export of your IDP again, the imported cert should be used inside the XML
I am trying to integrate SAML in an ongoing project for one of our clients. I am new to Okta and its services. The only thing, the client wants to input okta URL and upload certificate in the admin panel. Rest I have to create a login module using okta. My question is what is the use of a certificate? How can I use that certificate in the project? If possible please share any info on how to develop this in PHP preferable.
Two reasons a client ( presumably the application requiring SSO with Okta ) would provide you with a certificate.
1) They are signing the SAML Request, in which case you need to be able to verify the signature. I don't believe OKta supports signed requests, which would rule this out.
2) They want the SAML Response encrypted. In which case you would include the public key provided in the Okta application configuration.
Niall
Hopefully this isn't a duplicate or too broad. I just have a feeling I need a bit more information than anything else I've been able to find.
I have a program/server that already has a functioning SAML SP built in to it. I'm trying to get it connected to a test Shibboleth IdP (V3.3.3) on an internal server running Windows Server. I have it installed and connected to our Active Directory users. The documentation was great for getting to that point.
Now I have no earthly clue how to proceed. I see a lot of information about exchanging configuration/XML info and certificates between SPs and IdPs. I believe I have a valid SP XML and certificate to give to the IdP, but I don't know:
Where to put the SP XML information in the IdP installation
Where to put the SP certificate in the IdP installation (or setup/configure a path to a certificate)
Where to get the IdP certificate (I think the default setup generates something for me? Unclear)
Where the IdP login path is
Whether or not there's anything else I need to configure to get the two talking
1 through 4 are probably my biggest confusions that I can't seem to find info on. The Shibboleth documentation seems to assume I am far more familiar with configuring an IdP than I am. It tells me where to configure literally anything/everything possible, but I don't know what I should be configuring.
Anyhow, thanks for any help on this. I've been wasting a pitiful amount of time trying to figure this out.
To answer your five (5) questions, without loss of generality, we assume that
(I) the metadata file of SAML IdP is idpsaml-metadata.xml
(II) the metadata file of SAML SP is sp-example-org.xml
Q&A
Where to put the SP XML information in the IdP installation
Answer: /opt/shibboleth-idp/metadata/sp-example-org.xml
Where to put the SP certificate in the IdP installation (or setup/configure a path to a certificate)
Answer: The metadata file of SAML SP consists of the SP certificate.
SAML IdP will extract SP certificate from SAML SP's metadata (e.g., sp-example-org.xml)
Where to get the IdP certificate (I think the default setup generates something for me? Unclear)
Answer: The metadata file of SAML IdP consists of all the IdP certificates (which have been generated by the default setup of SAML IdP).
You need to place the metadata file of SAML IdP (e.g., idpsaml-metadata.xml) into the SAML SP's home directory, e.g., /etc/shibboleth/idpsaml-metadata.xml
Where the IdP login path is
Answer: Usually SAML SP uses HTTP-POST endpoint as SAML IdP login path, e.g.,
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://IdP-Server-URL/idp/profile/SAML2/POST/SSO"/>
You also need to configure Shibboleth IdP with LDAP user authentication.
/opt/shibboleth-idp/conf/idp.properties
/opt/shibboleth-idp/conf/ldap.properties
/opt/shibboleth-idp/conf/attribute-filter.xml
/opt/shibboleth-idp/conf/attribute-resolver-full.xml
Whether or not there's anything else I need to configure to get the two talking
Answer: To allow SAML IdP to provide identity authentication for SAML SP, both SAML IdP and SAML SP need to exchange their metadata.
Then you need to configure SAML IdP with SAML SP.
SAML IdP
/opt/shibboleth-idp/conf/metadata-providers.xml
/opt/shibboleth-idp/conf/relying-party.xml
SAML SP
/etc/shibboleth/shibboleth2.xml
/etc/shibboleth/attribute-map.xml
Remarks:
How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the sample configuration files for Shibboleth IdP and SP.
We are trying to federate our application, so that our customers can gain access to our application using their respective corporate identities.
Well, I understand the mechanism of federation process, I’ve been able to setting up ADFS and I’ve modified the code of our application for accepting claims into my lab environment and all work fine.
In the next weeks I’m going to build a federation trust between ADFS and our customer’s product (Ping Identity) and I need your help to understand what kind of information I’ll have to exchange with customer’s IT department to complete that step.
I’ve never been experience with Ping Identity products.
Appreciate any help.
Many Thanks
I am going to make a couple of assumptions about your application, mainly that it is .NET application hosted on IIS. This type of application integrates Windows Identity Foundation (WIF) using tags in the web.config and then reads the authenticated users identity information via the Claims Identity object passed to your application. In this case your application is referred to as the Service Provider (SP).
If your customer is using PingFederate, the integration is straightforward in that a WS-Federation SP Connection would be configured on their server referred to as the Identity Provider (IdP). If your customer is using PingOne, then the integration will be tricky.
The information to exchange for PingFederate is driven by the configuration in the configuration in web.config. You need to configure the thumbprint which is based on the digital signing certificate of the WS-Federation response containing the SAMLv1.1 token. Your customer will be able to provide the thumbprint value. You will also need to configure the federated authentication URL, issuer, and realm, which is the information about PingFederate IdP server. The issuer is the URL for your SP application to redirect to the PingFederate IdP server, along with the realm which equates to the PingFederate SP Connection. Be sure that you configure the audienceUris to be the same value as the realm. The PingFederate administrator will need to know your Service URL endpoint which is your SP application endpoint to receive the WS-Federation response with the SAMLv1.1 token.
I've got a site acting as an Identity Provider (IdP) for Single Sign on and another 2 service providers that authenticate against it using SAML 2. At the moment, both service providers use the same certificate to validate the SAML response from the IdP.
I've now got a 3rd Service Provider joining shortly and I wondered whether I should really be issuing separate certificates to each party so that we could potentially revoke their access, if required, without affecting the other Service Providers? What approach have others taken and why?
I'm using SimpleSamlPHP as the IdP.
As I understand, what you want is to be able to revoke SSO access for one SP but not all.
I would think this should not be done by revoking certificates but rather by removing the metadata from SimpleSamlPHP.
The problem with this is that the certificate information is in the IDP metadata that is sent to the SP and the metadata normally only allows for one certificate for one task (can be different tasks e.g. for signing and encryption).
Coming back the other way e.g. signing the SP Authn request, all the SP's can have different cetificates or they can share.
Some products e.g. ADFS 2.0 before Rollup 3 do not allow SP to share certificates.