&Tech blog & Web labs
How and When To Enable MySQL Logs
source: Blue and pink dolphins at work
If you are a web developer, you need to refer to various log files, in order
to debug your application or improve its performance. Logs is the best
place to start troubleshooting. Concerning the famous
database server
server), you
need to refer to the following log
. It contains information about
errors that
occur while the server is running (also server start and stop)
. This is a general record
of what mysqld is doing (connect, disconnect, queries)
. Ιt consists of "slow" SQL
statements (as indicated by its name).
This article does not refer to The Binary Log. This requires very high standards
server hardware and is
useful only in special cases (e.g. replication, master - slaves setup,
certain data recovery operations). Οtherwise, it is just a "performance
The official documentation about MySQL logs is available here.
Enable logs from MySQL configuration
Logging parameters are located under [mysqld] section.
Edit MySQL configuration file:
nano /etc/f
This is the default setup for Logging and Replication (in
server). In
other distributions the structure may be different, but you can always use
MySQL server
parameters:
# * Logging and Replication
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file
= /var/log/mysql/mysql.log
#general_log
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_f.
# Here you can see queries with especially long duration
#log_slow_queries
= /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
other settings you may need to change.
#server-id
= /var/log/mysql/mysql-bin.log
expire_logs_days
max_binlog_size
#binlog_do_db
= include_database_name
#binlog_ignore_db
= include_database_name
All log files are NOT enabled by default MySQL setup (except the error log on
Windows). Default Debian setup sends Error log to syslog. The other log files are not enabled.
Error Log goes to syslog due to
/etc/mysql/conf.d/mysqld_f, which contains the
following:
[mysqld_safe]
This is the recommended method. If, for some reason, you do
not want Error
log to go to syslog, comment the above lines in /etc/mysql/conf.d/mysqld_f
or completely remove this file. Then, add in /etc/f
the following lines:
[mysqld_safe]
log_error=/var/log/mysql/mysql_error.log
log_error=/var/log/mysql/mysql_error.log
General Query Log
To enable General Query Log, uncomment (or add) the relevant lines
general_log_file
= /var/log/mysql/mysql.log
general_log
Slow Query Log
To enable Slow Query Log, uncomment (or add) the relevant lines
log_slow_queries
= /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes
Restart MySQL server after changes
This method requires a server restart.
service mysql restart
systemctl restart mysql.service
Enable logs at runtime
Since MySQL 5.1 you can enable and disable logs at runtime.
To enable logs at runtime, login to mysql client (mysql -u root
-p ) and give:
SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';
To disable logs at runtime, login to mysql client (mysql -u root
-p ) and give:
SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';
This method works on any platform and does not require a server restart.
Display log results
With the above settings, you can
display Error log using
tail -f /var/log/syslog
REMARK: If you do not specify Error log file, MySQL keeps Error log at data
dir (usually
/var/lib/mysql
in a file named {host_name}.err).
General Query log
With the above settings, you can
display General log using
tail -f /var/log/mysql/mysql.log
REMARK: If you do not define General log file, MySQL keeps General log at
(usually /var/lib/mysql
in a file named {host_name}.log).
Slow Query log
With the above settings,
display Slow Query log using
tail -f /var/log/mysql/mysql-slow.log
REMARK: If you do not specify Slow Query log file, MySQL keeps Slow Query log
at data dir
(usually /var/lib/mysql
in a file named {host_name}-slow.log).
Log rotation
Do NOT ever forget to rotate logs. Otherwise, log files may become huge.
(and Debian derivatives as Ubuntu etc) log rotation using logrotate
is already present after initial server setup ("Debian packages
pre-configuration").
nano /etc/logrotate.d/mysql-server
in other distributions, some changes may be needed
# - I put everything in one block and added sharedscripts, so that mysql gets
flush-logs'd only once.
Else the binary logs would automatically increase by n times every day.
# - The error log is obsolete, messages go to syslog now.
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
create 640 mysql adm
sharedscripts
postrotate
test -x /usr/bin/mysqladmin || exit 0
# If this fails, check debian.conf!
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/f"
if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
# Really no mysqld or rather a missing debian-sys-maint user?
# If this occurs and is not a error please report a bug.
#if ps cax | grep - then
if killall -q -s0 - then
$MYADMIN flush-logs
Check out your server configuration
TIP: Use show variables like '%log%'; to examine your server
variables related to log files
root@cosmos ~ # mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.
Your MySQL connection id is 144332
Server version: 5.5.31-0+wheezy1 (Debian)
Copyright (c) , Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
Type '' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show variables like '%log%';
+-----------------------------------------+--------------------------------+
| Variable_name
+-----------------------------------------+--------------------------------+
| back_log
| binlog_cache_size
| binlog_direct_non_transactional_updates | OFF
| binlog_format
| STATEMENT
| binlog_stmt_cache_size
| expire_logs_days
| general_log
| general_log_file
| /var/lib/mysql/cosmos.log
| innodb_flush_log_at_trx_commit
| innodb_locks_unsafe_for_binlog
| innodb_log_buffer_size
| innodb_log_file_size
| innodb_log_files_in_group
| innodb_log_group_home_dir
| innodb_mirrored_log_groups
| log_bin_trust_function_creators
| log_error
| log_output
| log_queries_not_using_indexes
| log_slave_updates
| log_slow_queries
| log_warnings
| max_binlog_cache_size
| max_binlog_size
| max_binlog_stmt_cache_size
| max_relay_log_size
| relay_log
| relay_log_index
| relay_log_info_file
| relay_log_purge
| relay_log_recovery
| relay_log_space_limit
| slow_query_log
| slow_query_log_file
| /var/lib/mysql/cosmos-slow.log |
| sql_log_bin
| sql_log_off
| sync_binlog
| sync_relay_log
| sync_relay_log_info
+-----------------------------------------+--------------------------------+
41 rows in set (0.00 sec)
Server variables official documentation is available here.
When to enable logs
Using default MySQL setup, all log files are NOT enabled (except the error log on
Windows). Default
setup sends Error log to syslog.
Actually, there many situations where log files can provide solutions to critical problems:
Always enable Error log.
Enable General query log (preferably at runtime) when you want to
check that your application handles correctly MySQL database connection
(a common mistake is to connect multiple times to MySQL from a single
monitor executed queries from your application
(or similar software), checking out if a query was
executed or memcached has handled the request
Enable Slow Query log (preferably from MySQL configuration file for a short period of time, e.g. 2-3 days) when your
application performance is reduced for some reason and you should detect the slow
Here is an example of MySQL General query log:
43 Connect root@localhost as anonymous on pnet_blog
43 Init DB pnet_blog
43 Query SELECT count(id) as total_posts FROM posts WHERE date_published is not null AND date_published <= '50'
43 Query SELECT * FROM posts WHERE date_published is not null AND date_published <= '50' ORDER BY date_published DESC LIMIT 0,10
44 Connect root@localhost as anonymous on pnet_blog
44 Query SELECT id, title, impressions FROM tips WHERE date_published IS NOT NULL AND date_published <= '50' ORDER BY date_published DESC LIMIT 0, 10
45 Connect root@localhost as anonymous on pnet_blog
45 Init DB pnet_blog
45 Query SELECT * FROM posts WHERE url='how-and-when-to-enable-mysql-logs'
45 Query UPDATE posts SET impressions=impressions+1 WHERE id='41'
45 Query SELECT url, post_title FROM posts WHERE date_published IS NOT NULL AND date_published
'00' ORDER BY date_published ASC LIMIT 0,1
45 Query SELECT * FROM posts WHERE date_published is not null AND date_published = '28' ORDER BY impressions DESC LIMIT 0,10
46 Connect root@localhost as anonymous on pnet_blog
46 Query SELECT id, title, impressions FROM tips WHERE date_published IS NOT NULL AND date_published <= '28' ORDER BY date_published DESC LIMIT 0, 10
Related Posts
You may also be interested in
for our free email
newsletter.
tutorials and tips are published. You can unsubscribe
anytime with a click.
Please enable JavaScript to view the comments poweredFrom ServiceNow Wiki
& SAML & SAML 2.0 Web Browser SSO Profile
Note: The latest release this documentation applies to is Fuji. For the Helsinki release, see . Documentation for later releases is also on .
SAML 2.0 Overview
The Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains.
exchanges security information between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee. When implemented correctly, SAML is one of the most secure methods of single sign-on available.
integration enables single sign-on by
with an external Identity Provider (IdP). The identity provider authenticates the user and passes a NameID token to the ServiceNow system. If the ServiceNow system finds a user with a matching NameID token (for example, the email address), the instance logs in that user.
If you are using the SAML 2.0 plugin for Single Sign-on authentication, then you need to set the glide.ui.rotate_sessions property to false. Otherwise, it interferes with the session information sharing that takes place between ServiceNow and the Identity Provider. Users with the security_admin elevated privilege can access this high security property by selecting System Security & High Security Settings.
Note: It is recommended that customers using an existing SAML 2.0 integration upgrade to the latest .
SAML 2.0 Update 1
The SAML 2.0 Single Sign-On - Update 1: security enhancements plugin improves integration security by requiring additional checks against the SAMLResponse URL parameter. The integration explicitly checks the SAML response for the proper Identity Provider (IdP) and intended audience URLs.
SAMLResponse Validations
With Update 1, the integration validates these elements in the SAMLResponse.
The Issuer element matches the value listed in the issuer system property
The SubjectConfirmation and SubjectConfirmationData elements have a proper Recipient attribute
The AudienceRestriction and Audience elements match the value listed in the audience system property
Support for Signed SingleLogoutRequest
With Update 1, the SAML 2.0 integration has the option to sign SingleLogoutRequest elements. Some IdPs, such as Microsoft ADFS, require a signed SingleLogoutRequest.
Support for AuthnContextClass
With Update 1, the SAML 2.0 integration has the option to specify the method by which the IdP authenticates the user in the AuthnContextClass element. For example, the integration can now specify contexts such as form-based Password Protected Transport or Kerberos. See
for instructions on setting an authentication context class.
Support for RSA SHA-256
The instance supports signing of SAML assertions with RSA SHA-256, which is recommended over SHA-1.
New Properties
The SAML 2.0 Update 1 plugin includes the following new system properties.
Description
The Identity Provider URL which will issue the SAML2 security token with user info.
glide.authenticate.sso.saml2.idp
Enter the value of the Issuer element that the integration uses to validate the IdP URL. See
for a sample SAMLResponse message.
Sign LogoutRequest. Set this property to true if the Identity Provider's SingleLogoutRequest service requires signed LogoutRequest.
glide.authenticate.sso.saml2.require_signed_logoutrequest
Select whether the IdP requires a signed logout request.
URL to redirect users after logout, typically back to the portal that enabled the SSO (e.g. /logout)
glide.authenticate.external.logout_redirect
Enter the URL where the integration redirects users after they log out. Typically, you set this property to a UI page if you are using Kerberos authentication to prevent users from being redirected back to the IdP and logging in again after a logout request.
The audience uri that accepts SAML2 token. (Normally, it is your instance URI. For example: https://&instance name&..)
glide.authenticate.sso.saml2.audience
Enter the value of the Audience element that integration uses to validate the SP URL in the SAMLResponse.
Create an AuthnContextClass request in the AuthnRequest statement.
glide.authenticate.sso.saml2.createrequestedauthncontext
Select whether to create an AuthnContextClass element in the SAMLRequest that specifies the login mechanism the IdP should use to authenticate the user. Not all IdPs support a AuthnContextClass element in the SAMLRequest. If you select Yes, you must specify the URN of the context class with the glide.authenticate.sso.saml2.authncontextclassref property.
The AuthnContextClassRef method that we will request in our SAML 2.0 AutnReqeust to the Identity Provider
glide.authenticate.sso.saml2.authncontextclassref
Enter the URN of the login mechanism you want the IdP to use to authenticate users. For example, by default the ServiceNow system uses the forms-based Password Protected Transport authentication context .
The alias of key entry stored in SAML 2.0 SP Keystore used to sign SAML 2 requests.
glide.authenticate.sso.saml2.signing_key_alias
Enter the alias of the key that signs SAML 2 logout requests. You will have to create a Java Keystore for the alias.
The password of key entry stored in SAML 2.0 SP Keystore used to sign SAML 2 requests.
glide.authenticate.sso.saml2.signing_key_password
Enter the password for the key that signs SAML 2 logout requests.
The number in seconds before "notBefore" constraint, or after "notOnOrAfter" constraint, to consider still valid.
glide.authenticate.sso.saml2.clockskew
Enter the number of seconds between the two attributes that make up the SAMLResponse nonce. A valid SAMLResponse must fall between the notBefore and notOnOrAfter date-time values. See
for a sample SAMLResponse message.
These properties are available with the .
Description
AuthnRequest URL for eSignature Authentication.
com.snc.integration.saml_esig.idp_authnrequest_url
Enter the URL that points to the SAML 2.0 Identity Provider AuthnRequest Consumer for eSignature Authentication. In most cases, this will be the same as the AuthnRequest URL used in general authentication.
Leave this setting blank if you intend to use the same AuthnRequest Consumer URL that is used for general SAML 2.0 authentication in your instance.
The SAML 2.0 Assertion Consumer URL for eSignature authentication.
com.snc.integration.saml_esig.approval_consumer_url
In most cases, this URL will be: . However, if you employ a customized method of handling the SAML authentication for eSignature, you can set up your own consumer URL.
The SAML 2.0 Assertion Consumer Index for eSignature authentication
com.snc.integration.saml_esig.assertion_consumer_service_index
If your Service Provider has more than one URL set for the AssertionConsumerURL, you can set the index to use for eSignature, starting with index 1 or more.
Authentication Pop-up Dialog Width
com.snc.integration.saml_esig.popup_dlg_width
When a user approves a request using eSignature, a dialog allows the user to enter their credentials. This setting controls the width of that dialog box.
Authentication Pop-up Dialog Height
com.snc.integration.saml_esig.popup_dlg_height
When a user approves a request using eSignature, a dialog allows the user to enter their credentials. This setting controls the height of that dialog box.
Login (AuthnRequest) Process Flow
SAML 2.0 specifies a Web Browser SSO Profile that involves exchanging information among an identity provider (IdP), a service provider (SP), and a principal (user) on a web browser. The identity provider can be any SSO service offering SAML authentication services (for example SSOCircle). The service provider is always a ServiceNow instance. The message flow begins with a request for a secured resource at the service provider.
1. Request the target resource at the SP
The principal requests a target resource at the service provider:
https://instance./
The ServiceNow instance checks the request to see if the SAMLRequest and RelayState URL parameters are present. If they exist, the user has already validated with the IdP and can skip steps 2&#8211;6.
2. Issue AuthnRequest to Identity Provider
ServiceNow instance constructs an AuthnRequest to be sent to the IdP using the SAMLRequest value.
The instance also constructs and sends a RelayState URL parameter value.
The RelayState token is an opaque reference to state information maintained at the service provider.
The value of the SAMLRequest parameter is the deflated and base64 encoded value of the &samlp:AuthnRequest& element:
&samlp:AuthnRequest
xmlns:samlp=&urn:oasis:names:tc:SAML:2.0:protocol&
xmlns:saml=&urn:oasis:names:tc:SAML:2.0:assertion&
ID=&identifier_1&
Version=&2.0&
IssueInstant=&T09:21:59Z&
AssertionConsumerServiceIndex=&0&&
&saml:Issuer&/SAML2&/saml:Issuer&
&samlp:NameIDPolicy
AllowCreate=&true&
Format=&urn:oasis:names:tc:SAML:2.0:nameid-format:transient&/&
&/samlp:AuthnRequest&
The integration then URL-encodes the &samlp:AuthnRequest& element and sends it as the SAMLRequest URL parameter.
The SSO service processes the &samlp:AuthnRequest& element by URL-decoding, base64-decoding and inflating the request, in that order. It then performs a security check.
If the user does not have a valid security context, the IdP identifies the user by prompting for login credentials. If the user is already logged in, the IdP simply responds with the SAMLResponse&tt& and &tt&RelayState URL parameters (see step 3).
3. Respond with an SAMLResponse and RelayState
After collecting the required login credentials, the SSO service validates the request and responds with a document containing an XHTML form:
&form method=&post& action=&https://instance./navpage.do& ...&
&input type=&hidden& name=&SAMLResponse& value=&response ...& /&
&input type=&hidden& name=&RelayState& value=&token ...& /&
&input type=&submit& value=&Submit& /&
The value of the RelayState parameter comes from this step.
The value of the SAMLResponse parameter is the base64 encoding of the following &samlp:Response& element:
&samlp:Response xmlns:samlp=&urn:oasis:names:tc:SAML:2.0:protocol&
ID=&s2cdc74f37f923e26fe1aeec42b70a93df&
InResponseTo=&90AABFB0DF194F&
Version=&2.0&
IssueInstant=&T23:21:51Z&
Destination=&https://dloomac./navpage.do&&
&saml:Issuer xmlns:saml=&urn:oasis:names:tc:SAML:2.0:assertion&&&/saml:Issuer&
&samlp:Status xmlns:samlp=&urn:oasis:names:tc:SAML:2.0:protocol&&
&samlp:StatusCode xmlns:samlp=&urn:oasis:names:tc:SAML:2.0:protocol&
Value=&urn:oasis:names:tc:SAML:2.0:status:Success&&
&/samlp:StatusCode&
&/samlp:Status&
&saml:Assertion xmlns:saml=&urn:oasis:names:tc:SAML:2.0:assertion&
ID=&s23e536bfc51b9dec162d9c2e338823b&
IssueInstant=&T23:21:51Z&
Version=&2.0&&
&saml:Issuer&&/saml:Issuer&
&Signature xmlns=&http://www.w3.org/2000/09/xmldsig#&&
&/Signature&
&saml:Subject&
&saml:NameID Format=&urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress&
NameQualifier=&&
SPNameQualifier=&https://dloomac./navpage.do&&david.loo@&/saml:NameID&
&saml:SubjectConfirmation Method=&urn:oasis:names:tc:SAML:2.0:cm:bearer&&
&saml:SubjectConfirmationData
InResponseTo=&90AABFB0DF194F&
NotOnOrAfter=&T23:31:51Z&
Recipient=&https://dloomac./navpage.do& /&
&/saml:SubjectConfirmation&
&/saml:Subject&
&saml:Conditions NotBefore=&T23:11:51Z&
NotOnOrAfter=&T23:31:51Z&&
&saml:AudienceRestriction&
&saml:Audience&https://dloomac.&/saml:Audience&
&/saml:AudienceRestriction&
&/saml:Conditions&
&saml:AuthnStatement AuthnInstant=&T23:21:51Z&
SessionIndex=&s2dbf89abcdaedb21b968a04&&
&saml:AuthnContext&
&saml:AuthnContextClassRef&urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport&/saml:AuthnContextClassRef&
&/saml:AuthnContext&
&/saml:AuthnStatement&
&/saml:Assertion&
&/samlp:Response&
4. Validate SAMLResponse
The SAMLResponse value is base64 decoded and inflated to reveal the XML document in step 3.
The ServiceNow login script extracts the XML value from the //Subject/NameID element and uses it to look up an existing user in the User table.
The login script also extracts the session ID from the //AuthnStatement/@SessionIndex element and stores it for the LogoutRequest.
Logout (LogoutRequest) Process Flow
During logout, ServiceNow issues the SAML 2.0 LogoutRequest service call to the IdP.
This service logs the user out and then redirects back to the specified logout URL.
Logout SAML 2.0 Web Browser SSO (POST)
1. User Clicks the Logout Button
The user clicks the Logout button and the instance executes the logout script.
2. LogoutRequest issued
The logout script constructs a SAML 2.0 LogoutRequest and posts it to the preconfigured SingleLogoutRequest SAML 2.0 service at the IdP.
The IdP deflates the request and then base64 encodes it. An example LogoutRequest looks like this:
&saml2p:LogoutRequest xmlns:saml2p=&urn:oasis:names:tc:SAML:2.0:protocol&
ID=&21B78E9C6C8ECF16F01E4A0F15AB2D46&
IssueInstant=&T21:36:11.230Z&
Version=&2.0&&
&saml2:Issuer xmlns:saml2=&urn:oasis:names:tc:SAML:2.0:assertion&&https://dloomac.
&/saml2:Issuer&
&saml2:NameID xmlns:saml2=&urn:oasis:names:tc:SAML:2.0:assertion&
Format=&urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress&
NameQualifier=&&
SPNameQualifier=&https://dloomac./navpage.do&&david.loo@&/saml2:NameID&
&saml2p:SessionIndex&s211b2fa1d2cc4db2b771104
&/saml2p:SessionIndex&
&/saml2p:LogoutRequest&
3. User Logs Out
The user logs out of the IdP. The IdP redirects back to ServiceNow, which in turns redirects back to the IdP since the user is not logged in.
Adding Support for E-Signature
When E-signature is active with Multi-SSO, SAML properties are not used. The system adds E-signature properties to the SAML2 Update1 Properties [saml2_update1_properties] table:
Assertion Consumer Index for eSignature authentication: An index number that identifies the endpoint. The default value is 1.
Assertion Consumer URL for eSignature authentication: your instance URL.
AuthnRequest URL for eSignature Authentication: the URL for authentication.
If you are using E-Signature with SAML 1.0 or SAML 2.0 (not including update 1), see the special configuration instructions: .
Note: If you are a Life Science Customer using E-Signature, you must deactivate the User self-lockout prevention business rule, which is new with Fuji. See
for more information.
Adding Support for Deep Linking
Deep linking allows ServiceNow instances to support direct email links to a particular record in the system. With the SAML 2.0 integration enabled, deep-linking URLs must pass an authentication check before the IdP redirects
the user to the originally requested URL. For example, if an email contains this URL:
https://&instance name&./nav_to.do?uri=incident.do?sys_id=46c88ac1a9fec831fbcf6d
The instance sends an authentication request to the IdP and uses the RelayState URL parameter to preserve the originally requested resource (in this case, uri=incident.do?sys_id=46c88ac1a9fec831fbcf6d). After the IdP authenticates the user, the instance reads the value of the RelayState URL parameter and redirects the user to the requested resource (if it exists in the instance).
To add support for deep linking verify that the identity provider supports the RelayState URL parameter.
Monitoring the Event Queue for Login Failures
The SAML 2.0 integration creates the following
for login activities. You can use these events to monitor for login failures and determine if there are any security concerns to address.
Event Name
Description
Parameter 1
Parameter 2
saml2.logout.validation.failed
The logout response from the IdP failed validation against your logout request. The event validates the &inResponseTo& element against the session ID (ID attribute of the &saml2p:LogoutRequest& element). For example, see the workflow for .
Session ID
The string, "SAML2 LogoutResponse validation failed.'
external.authentication.succeeded
External authentication succeeded and the user accessed the instance URL.
Session ID
User ID of user who successfully logged in
The URL the user accessed (which may be a )
external.authentication.failed
The single sign-on requirements are not present or are missing.
Session ID
The missing authentication requirements
external.authentication.failed
The user does not exist in the User [sys_user] table
The string, "User does not exist"
external.authentication.failed
The user is locked out.
The string, "User locked out."
Examples of Third-Party SAML Identity Providers Configurations
While ServiceNow does not typically provide instructions for configuring third-party SAML IdP products, customers occasionally provide examples of how they have implemented their SAML IdP with ServiceNow. These documents provide examples of possible IdP setup configurations.
Note: ServiceNow does not provide support for these example configurations.
Identity Provider
Example Setup
Microsoft Active Directory Federation Services 2.0
Enhancements
Supports encrypted SAML assertions when Multi-Provider Single Sign-on is enabled. See
for descriptions of the settings you need to configure.
Support for multiple provider single sign-in configuration. See
for more information.
A new set of system properties support using E-Signature with SAML 2.0 update 1.
Administrators can require the Identity Provider's single-sign on service to sign logout requests. Use the new system property glide.authenticate.sso.saml2.require_signed_authnrequest. See
for more information.
Was this article helpful?Yes, I found what I neededNo, I need more assistance
This page was last modified 13:24, 22 December 2016.