We share advice on using Okta as an industry-standard SAML2 Identity Provider.
For all true support questions regarding Okta – or any non-Intercax provider of SAML2 service – please contact the vendor directly through their formal Support programs.
Okta “Applications”
In Okta, each integration between a particular Service Provider (like Syndeia) and Okta as the IdP is configured by administering within Okta the creation of a new “Okta Application”, an application that offers SAML2 support.
Therefore, each time you deploy Syndeia to a particular server, you will create a new separate “Okta Application” just for that Syndeia server - even if you already set up SAML2 integration with Okta for other Syndeia servers.
Okta is its own Directory Service of Users
In addition to being able to act as a proxy between existing, often legacy, directory services such as OpenLDAP services and Microsoft ActiveDirectory services, Okta can be and often does act as its own Directory Service of Users and may even be the primary, definitive directory of user accounts.
When Okta is the Directory Service, configuration of Okta as the SAML2 IdP is trivial because there is no need to configure integration with an external IdP.
Okta User Profile Attributes
Make sure that the User Profile in the Okta Universal Directory includes populated attributes for all of:
First Name
Last Name
Email Address
At least those have to be passed along to the Syndeia SP in the SAMLResponse as Attributes. Syndeia needs names to display for the user and an email address to uniquely identify the user even as the user authenticates with numerous services.
Private Keys + Certificates
In addition, you will need to have & add the following:
SP Private Key
SP Certificate
IdP Certificate
Sample SAML2 silhouette.conf section
The following sample silhouette.conf sample SAML2 section excerpt gives a cumulative template showing all the values that pertain to configuring Okta’s (SaaS) SAML2 IdP implementation for use with Syndeia Cloud (SC), ie: the SP.
# ==================================================
# SAML2 Provider
# These settings are intentionally similar to what OneLogin needs for SAML2
# Service Providers and Identity Providers
# Compression settings. Note that these are determined by OASIS Standard for SAML2
# false => Base64 encoded, true => Deflated Base64 encoded (which is compressed)
# saml2.compress.request = true
# saml2.compress.response = true
saml2.security.authnrequest_signed = true
saml2.security.want_messages_signed = true
saml2.security.want_assertions_signed = true
saml2.security.want_xml_validation = true
saml2.security.signature_algorithm = "sha1"
saml2.security.requested_authncontext = "exact"
# CAC/PIV authentications might need something like this, which is IdP-specific
# saml2.security.requested_authncontext = "http://idmanagement.gov/ns/assurance/aal/3?hspd12=true"
# Identifier of the SP entity (must be a URI)
saml2.sp.entityid = "https://mySCserver.domain.tld:9443"
# Specifies info about where and how the <AuthnResponse> message MUST be
# returned to the requester, in this case our SP.
# URL Location where the <Response> from the IdP will be returned
saml2.sp.assertion_consumer_service.url = "https://mySCserver.domain.tld:9443/authenticate/SAML2"
# SAML protocol binding to be used when returning the <Response>
# message. Onelogin Toolkit supports for this endpoint the
# HTTP-POST binding only
saml2.sp.assertion_consumer_service.binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
# Specifies info about where and how the <Logout Response> message MUST be
# returned to the requester, in this case our SP.
saml2.sp.single_logout_service.url = "https://mySCserver.domain.tld/authenticate/SAML2"
# SAML protocol binding to be used when returning the <LogoutResponse> or sending the <LogoutRequest>
# message. Onelogin Toolkit supports for this endpoint the
# HTTP-Redirect binding only
saml2.sp.single_logout_service.binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
# Specifies constraints on the name identifier to be used to
# represent the requested subject.
# Take a look on lib/Saml2/Constants.php to see the NameIdFormat supported
saml2.sp.nameidformat = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
# Usually x509cert and privateKey of the SP are provided by files placed at
# the certs folder. But we can also provide them with the following parameters
saml2.sp.x509cert = "-----BEGIN CERTIFICATE-----<REDACTED>-----END CERTIFICATE-----"
# Requires Format PKCS#8 BEGIN PRIVATE KEY
# If you have PKCS#1 BEGIN RSA PRIVATE KEY convert it by openssl pkcs8 -topk8 -inform pem -nocrypt -in sp.rsa_key -outform pem -out sp.pem
saml2.sp.privatekey = "-----BEGIN PRIVATE KEY-----<REDACTED>-----END PRIVATE KEY-----"
# Identifier of the IdP entity (must be a URI)
saml2.idp.entityid = "http://www.okta.com/<org_id>"
# SSO endpoint info of the IdP. (Authentication Request protocol)
# URL Target of the IdP where the SP will send the Authentication Request Message
saml2.idp.single_sign_on_service.url = "https://intercaxtestintercaxworkforce.okta.com/app/<Okta_org_name>_<SC_servername>_1/<org_id>/sso/saml"
saml2.idp.single_sign_on_service.binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
# Instead of using the whole x509cert you can use a fingerprint in order to
# validate a SAMLResponse (but you still need the x509cert to validate LogoutRequest and LogoutResponse using the HTTP-Redirect binding).
# But take in mind that the fingerprint, is a hash, so at the end is open to a collision attack that can end on a signature validation bypass,
# that why we don't recommend it use for production environments.
# (openssl x509 -noout -fingerprint -in "idp_crt" to generate it,
# or add for example the -sha256 , -sha384 or -sha512 parameter)
# If a fingerprint is provided, then the certFingerprintAlgorithm is required in order to
# let the toolkit know which Algorithm was used. Possible values: sha1, sha256, sha384 or sha512
# 'sha1' is the default value.
#saml2.idp.certfingerprint = "1234"
#saml2.idp_certfingerprint_algorithm = "sha1"
saml2.idp.x509cert = "-----BEGIN CERTIFICATE-----<REDACTED>-----END CERTIFICATE-----"
# These are the property keys used to retrieve Social Identity information from the SAML2 Response which an IdP
# sends back to an SP. The names of the keys are standardized but are configurable here to support internationalization
# and quirks by IdP vendors like Microsoft
saml2.social.attribute.key.uid = "uid"
saml2.social.attribute.key.firstname = "first_name"
saml2.social.attribute.key.lastname = "last_name"
saml2.social.attribute.key.fullname = "fullname"
saml2.social.attribute.key.email = "email"
Okta’s Guide to Configuring Okta as a SAML IdP
Visit Create SAML app integrations to learn what Okta advises for configuring its service for use as a SAML2 IdP.