Category Archives: Blog

Enable ‘Debug’ Logging in ADFS

Enabling 'Debug' Logging in ADFS

Enabling 'Debug' Logging in ADFS

Microsoft Active Directory Federation Services (ADFS) isn't the simplest SAML implementation to debug. When a new service provider ("relying party") integration isn't working, when configuring a new identity provider ("claims provider"), or just having issues with a particular user accessing a service, there is often little-to-no useful information within the default logs. That said, it's relatively simple to lower the logging level:

Set Trace level and Enable the ADFS Tracing Log

  1. Run command prompt as an administrator.

  2. Type the following command:

    wevtutil set-log “AD FS Tracing/Debug” /L:5
  3. Open Event Viewer.

  4. Right-click on Application and Services Logs.

  5. Select View -> "Show Analytics and Debug Logs"

  6. Navigate to Applications and Services Logs -> AD FS Tracing –> Debug.

  7. Right-click and select "Enable Log" to start trace debugging immediately.

To stop tracing, similarly:

  1. Follow Steps 1-6 above.
  2. Right-click and select "Disable Log" to stop trace debugging. It is difficult to scroll and search in the events page by page in the debug log, so it is recommended that you save all debug events to a *.evtx file first.
  3. Open the saved log again and observe that it now includes ADFS Tracing events.

Note: Trace/Debug logs in ADFS are very chatty... and should be used with discretion, and only for the duration of troubleshooting activity, on production servers.

Enable Object Access Auditing to See Access Data

To observe detailed information about access activities on the ADFS servers you must enable object access auditing in two locations on the ADFS servers:

To Enable Auditing:

  1. On the primary ADFS server, right-click on Service.
  2. Select the Success audits and Failure audits checkboxes. These settings are valid for all ADFS servers in the farm.

To modify the Local Security Policy, do the following:

  1. Right-click the Start Menu, and select 'Run'
  2. Type gpedit.msc and select 'OK'
  3. Navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy
  4. In the policy list, right-click on Audit Object Access, and select 'Properties'
  5. Select the Success and Failure checkboxes. These settings have to be enabled in the Local Security Policy on each ADFS server (or in an equivalent GPO that is set in Active Directory).
  6. Click OK

Open the security event logs on the ADFS servers and search for the timestamps that correspond to any testing or troubleshooting that is being conducted.

Need help debugging an ADFS issue? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!

Shibboleth Logging 101

Shibboleth Logging 101

Shibboleth Logging 101

If you're installing, configuring, or managing a single sign-on environment, you will inevitably find yourself wanting (or needing) to understand what's going on under the hood. That's where log files come in. In this space, we've collected some useful general information about Shibboleth logging for both:


Shibboleth IdP Logging

Logging on Shibboleth IdP is implemented via an abstract layer (SLF4J) which directs control of logging to the Logback facility. Since the project depends upon these logging implementations, Shibboleth is somewhat beholden to configuring via these external methods. Thankfully, they are relatively generic and highly customizable.

Logging is configured in %{idp.home}/conf/logback.xml, where %{idp.home} is the location where Shibboleth IdP is installed (typically, and by default, /opt/shibboleth-idp). Importantly, you don't usually need to adjust this file unless you want to make specific changes to the logging constructs, e.g. changing the format of the logged strings. Most of the major settings you'll need to adjust can be edited from %{idp.home}/conf/idp.properties.

Logs are stored within %{idp.home}/logs.

Logging Options for idp.properties

variable default function
idp.loghistory 180 Number of days of logs to keep
idp.process.appender IDP_PROCESS Appender to use for diagnostic log
idp.loglevel.idp INFO Log level for the IdP proper
idp.loglevel.ldap WARN Log level for LDAP events
idp.loglevel.messages INFO Set to DEBUG for protocol message tracing
idp.loglevel.encryption INFO Set to DEBUG to log cleartext versions of encrypted content
idp.loglevel.opensaml INFO Log level for OpenSAML library classes
idp.loglevel.props INFO Set to DEBUG to log runtime properties during startup
idp.loglevel.spring ERROR Log level for Spring Framework (very chatty)
idp.loglevel.container ERROR Log level for Tomcat/Jetty (very chatty)
idp.loglevel.xmlsec INFO Set to DEBUG for low-level XML Signing/Encryption logging

"Debug" Logging

When we say "turn up logging to DEBUG" we really mean that you should adjust one or more of the above properties in order to see more useful information. There's no fixed set, but in general:

  • If you're doing any kind of debugging you should set idp.loglevel.idp = DEBUG

  • If you want to see the actual SAML assertions, you should use a combination such as:

    idp.loglevel.idp = DEBUG
    idp.loglevel.messages = DEBUG
    idp.loglevel.opensaml = DEBUG
    idp.loglevel.encryption = DEBUG
  • If you're working on an issue with a data connector or attribute resolver, you might find:

    idp.loglevel.idp = DEBUG
    idp.loglevel.ldap = INFO

    to be all that you really need, however, you can always take idp.loglevel.ldap to DEBUG as well (though be aware, it's quite chatty).

WARNING: There is no reason to keep debug logging turned on in a production environment. This is especially true if you are capturing raw or decrypted SAML assertions. Don't do it. Tune things back to default by commenting out your changes when you're done! You have been warned.

More information about Shibboleth IdP Logging can be found on the wiki!


Shibboleth SP Logging

The Shibboleth SP software writes to two separate diagnostic log files by default, as configured by the shibd.logger and native.logger logging setup files. The first file governs most of the interesting "SAML" bits, like assertion receipt, decryption, and attribute resolution. These events will be logged into a file named shibd.log within the default log directory (unless modified):

  • Linux systems: /var/log/shibboleth
  • Windows systems: C:\opt\shibboleth-sp\var\log\shibboleth

native.logger controls messages related to RequestMapping, and more often than not isn't needed. However, once caveat is that on Windows systems using IIS the default configuration leads to no creation of a simple native.log file. This can be easily addressed.

"Debug" Logging

Overall behavior is specified by the log4j.rootCategory parm in shibd.logger, which is by default:

log4j.rootCategory=INFO, shibd_log, warn_log

bumping this to DEBUG is minimally necessary for most debugging.

Debugging assertions

If you are interested in seeing the SAML assertions themselves, set:

log4j.category.OpenSAML.MessageDecoder=DEBUG
log4j.category.OpenSAML.MessageEncoder=DEBUG

by un-commenting these lines in shibd.loggger.

WARNING: There is no reason to keep debug logging turned on in a production environment. This is especially true if you are capturing raw or decrypted SAML assertions. Don't do it. Tune things back to default by commenting out your changes when you're done! You have been warned.

More information about Shibboleth SP Logging can be found on the wiki!

Need help debugging a Shibboleth issue? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!

SameSite Cookies and Shibboleth

SameSite Cookies and Shibboleth

SameSite Cookies and Shibboleth

Google Chrome v.80 is slated to be deployed to the stable channel on February 4th, 2020. (Note: some sources indicate Feb. 17th as the release target.) With this update comes a fundamental shift in the default handling of cookies within Chrome. Starting with this release, cookies will by default be treated as though they have the property SameSite=lax, instead of this property being unset.

The SameSite cookie attribute is a IETF draft written by Google Inc. which instructs the user-agent not to send the SameSite cookie during a cross-site HTTP request. The aim of the SameSite property is to help prevent certain forms of cross site request forgery. Cross-site HTTP requests are those for which the top level site (i.e. that shown in an address bar) changes during navigation.

The SameSite attribute can take three values:

  • strict - only attach cookies for ‘same-site’ requests.

  • lax - send cookies for ‘same-site’ requests, along with ‘cross-site’ top level navigations using safe HTTP methods e.g. (GET HEAD OPTIONS TRACE).

  • none - send cookies for all ‘same-site’ and ‘cross-site’ requests.

The previous behavior of the Chrome browser would be equivalent to SameSite=None.


Ramification for Shibboleth Identity Provider

Per the Shibboleth Consortium, which conducted extensive testing of the Identity Provider software:

the IdP should continue to function when its cookies are being defaulted to SameSite=Lax by browsers (currently tested on Chrome 78-81 and Firefox 72 with the same-site default flags set). Typically, we have only seen the IdP itself break when the JSESSIONID is set to SameSite=strict, which should not happen apart from when explicitly trying to set SameSite=none with older versions of Safari on MacOS <=10.14 and all WebKit browsers on iOS <=12 (Source)

They go on to list the following scenarios wherein SSO breaks, namely:

  • When using client side session storage, with htmlLocalStorage set to false, HTTP-POST SSO will not work (show login page again) with defaulted SameSite=Lax IdP cookies. However, when using client side session storage, with htmlLocalStorage set to true, and all bean references in shibboleth.ClientStorageServices are left as they are, HTTP-POST SSO will work with defaulted SameSite=Lax.

  • When using server side session storage, if either htmlLocalStorage or the bean references in shibboleth.ClientStorageServices are commented out, HTTP-POST SSO will not work (show login page again) with defaulted SameSite=Lax. Once again, however, when using sever side session storage, with htmlLocalStorage set to true, or all bean references in shibboleth.ClientStorageServices are left as they are, HTTP-POST SSO will work with defaulted SameSite=Lax.

Therefore, to take the relevant IdP-side steps necessary to guarantee SSO on existing installations of the IdP v3, you should enable the HTML Local Storage plugin whether you use client-side storage or server-side storage. This is achieved by setting the idp.storage.htmlLocalStorage property to true in idp.properties.

See the Shibboleth Wiki section re: StorageConfiguration for more information and the implications of this setting.

For more details on the Consortium's investigatory work related to SameSite please visit this wiki page.


Ramification for Shibboleth Service Provider

Unfortunately, as noted by the Shibboleth Consortium, the bulk of the issues likely to arise within service provider deployments lie solely within the application space, and are likely outside of the Shibboleth domain.

Nor can we provide any sort of yes/no or good/bad conclusion for anybody as to whether "their system is affected". That is going to depend entirely on the individual case and the only real answer is to test. (Source)

Effectively, SPs should really just test their systems prior to the expected launch of the SameSite changes in Chrome. You can test in either Firefox or Chrome:

Firefox

  • Enter about:config in the URL bar, Accept Risk and Continue
  • Type samesite to filter options to display: network.cookie.sameSite.laxByDefault
  • Set network.cookie.sameSite.laxByDefault to true

Chrome

  • Enter chrome://flags in URL bar
  • Type SameSite
  • Enable “SameSite by default cookies”

If your application fails to work under the test conditions, you can adjust the relevant (blocked) cookies in order to specify the SameSite=none directive. None of the cookies set by Shibboleth SP should require this directive, however, it is quite likely that you will need to adjust cookies within your application.

In particular, the notes from the Shibboleth Consortium further state that

... a typical source of problems for most applications is going to be load balancer behavior. If you're using cookies for node affinity, you're going to have problems with SameSite unless you do something about it.

and in particular, you should adjust your load balancer to specify SameSite=none for these affinity cookies.

Need help understanding how the SameSite cookie attribute affects your application or SSO environment? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!

Forced Authentication with Shibboleth SP

Forced Authentication with Shibboleth SP

Forced Authentication with Shibboleth SP

Single sign-on (SSO) allows users to authenticate once against an Identity Provider (IdP), and get "automatically" logged into one or more Service Providers (SPs), without need to re-authenticate for a period of time determined by the length of the IdP's "session" (often taking the form of a cookie stored in the user's browser).

Some services require an additional layer of security. They require the user to enter their login and password every time they enter the application. This is typically due to the nature of the application - i.e. higher-risk data like payroll - and hence the SP can send a SAML AuthnRequest with a special forceAuthn flag, like so:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="_d7d60924682b543f51b9f6eb9810b75e"
                    IssueInstant=""2020-01-01T00:00:00Z"
                    Destination="http://idp.example.com/idp/profile/SAML2/Redirect/SSO"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    AssertionConsumerServiceURL="http://sp.example.com/Shibboleth.sso/SAML2/POST"
                    Version="2.0"
                    ForceAuthn="true">
  <saml:Issuer>http://sp.example.com/shibboleth</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
  <samlp:NameIDPolicy AllowCreate="1" />
</samlp:AuthnRequest>

In order to configure Shibboleth SP to generate this kind of request, there are two elements in shibboleth2.xml that need to be adjusted:

<Sessions lifetime="28800" timeout="3600" relayState="ss:mem" maxTimeSinceAuthn="10"
          checkAddress="false" handlerSSL="true" cookieProps="https">

First, in the <Sessions> element, set the maxTimeSinceAuthn parameter to some short interval. This checks that an actual username and password was entered in the last specified number seconds (the example here sets it to 10 seconds).

Next, in the <SSO> block:

<SSO entityID="http://idp.example.com/idp/shibboleth" forceAuthn="true"
     discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
  SAML2 SAML1
</SSO>

add the forceAuthn flag set with a value of true.

Step Up Authentication

Note, that these settings can be applied in any application declaration, whether it be the default setting, or you utilize an ApplicationOverride to establish a second, logical SP. The latter scenario is often utilized when employing "step-up" authentication.

For example, you may have one or more paths which you'd want to protect with an added layer of security. In this case, you can deploy an ApplicationOverride that's also integrated with your partner IdP, and protect that content with the second application in Shibboleth. In terms of Apache config, it may look something like this:

<Location /secure>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  ShibRequestSetting entityID http://idp.example.com/idp/shibboleth
  require shib-session
</Location>

<Location /secure/supersecure>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  ShibRequestSetting applicationId MyForceAuthnApp
  ShibRequestSetting entityID http://idp.example.com/idp/shibboleth
  require shib-session
</Location>

where you configure an ApplicationOverride with the id MyForceAuthnApp to have the relevant <Sessions> and <SSO> blocks above.

Looking for support for Shibboleth? Look no further! Contact us for all of you SSO support needs!

Configuring the CAS Management Webapp

Configuring the CAS Management Webapp

Configuring the CAS Management Webapp

This guide documents how to spin-up the CAS Management Webapp as an Apache Maven overlay. (You can do it with Gradle as well, but I prefer Maven.)

1. Pull down the repo.

mkdir /opt/cas/
git clone https://github.com/apereo/cas-management-overlay.git

You can browser the repository here: apareo/cas.

2. Edit etc/cas/config/management.properties:

-- Add server names for CAS Management Webapp to authenticate, and details of the Management app itself:

cas.server.name: https://cas.example.edu
cas.server.prefix: https://cas.example.edu/cas
mgmt.serverName=https://idmutil04.kumc.edu
server.context-path=/cas-management
server.port=9443

-- Add service registry. NOTE: Must be exactly what the CAS server uses, i.e. if you use the following configuration for an LDAP service registry in cas.properties on the CAS server, make sure to include this same config blob here. The following example demonstrates the LDAP Service Registry

# LDAP Service Registry
cas.serviceRegistry.ldap.ldapUrl=[REDACTED]
cas.serviceRegistry.ldap.baseDn=ou=CasTestServiceRegistry,ou=Services,o=IDVAULT
cas.serviceRegistry.ldap.bindDn=cn=casserviceregistry,ou=AuthAccounts,o=IDVAULT
cas.serviceRegistry.ldap.bindCredential=[REDACTED]
cas.serviceRegistry.ldap.serviceDefinitionAttribute=description
cas.serviceRegistry.ldap.idAttribute=uid
cas.serviceRegistry.ldap.objectClass=casRegisteredService
cas.serviceRegistry.ldap.searchFilter=(%s={0})
cas.serviceRegistry.ldap.loadFilter=(objectClass=%s)

3. Edit the pom.xml.

Include any additional dependencies you may have. For example, to include the LDAP Service Registry dependency:

<!-- LDAP Service Registry -->
<dependency>
  <groupId>org.apereo.cas</groupId>
  <artifactId>cas-server-support-ldap-service-registry</artifactId>
  <version>${cas.version}</version>
  <exclusions>
    <exclusion>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Note that I needed to exclude the dependency's dependency on spring-web so that it wasn't included twice, otherwise you may get an error on startup such as this:

More than one fragment with the name [spring_web] was found. This is not legal with relative ordering. See section 8.2.2 2c of the Servlet specification for details. Consider using absolute ordering.

See: https://stackoverflow.com/questions/55177367/more-than-one-fragment-with-the-name-spring-web-was-found-in-non-maven-projec

4. Edit etc/cas/config/users.properties to add your users, i.e.

kellen=foo,ROLE_ADMIN

Note: The 'foo' is for a legacy password field, can be anything there. This is obviated if you use a JSON or YAML authorization list.

5. Build and deploy the WAR file to Tomcat:

./build.sh package
sudo install -C -m 775 -o tomcat -g root etc/cas/config/* /etc/cas/config
sudo install -C -m 775 -o tomcat -g root target/cas-management.war /opt/tomcat/webapps
sudo systemctl start tomcat

Resources:

https://apereo.github.io/cas-management/5.3.x/installation/Installing-ServicesMgmt-Webapp.html

Looking for support for CAS? Look no further! Contact us for all of you SSO support needs!

SSO Support for Busy IT Admins 5 — Managing Integrations

SSO Support for Busy IT Admins 5 — Managing Integrations

So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?

This post is the last in five-part series on the Fundamentals of SSO Support for IT Administrators. You can see our first post here, our second post here, our third post here, and our fourth post here.

Keeping Integrations in Order

The primary purpose for a Single Sign On environment is to central authentication, and make things simpler for your users. However, one of the items that seems to plague busy academic and enterprise environments is a highly disorganized and disjointed SSO configuration. Here are some tips for keeping your SSO integrations in order, so that it’s easier to managing being the SSO Support “guy”.

Centralize as much as possible.

Many times we see orgs that are using some combination of Shibboleth, CAS, ADFS, and OAuth all at the same time, often with different administrators for each vying for the role of being the “SSO Support Principal”. With certain exceptions, you should reduce the number of deployed SSO solutions within your org’s ecosystem to as few as possible… for example:

  • Shibboleth and ADFS are both primarily SAML-speaking IdP packages. Do you really need both? Did you know that you can delegate Shibboleth authentication to ADFS? Did you know that you can delegate ADFS authentication to Shibboleth?
  • CAS works with a proprietary protocol… but Shibboleth IdP “speaks” that protocol. Ditch CAS and get Shib!
  • But hey… CAS also “speaks” SAML… Ditch Shib and get CAS!
  • Shibboleth, CAS, and ADFS all support OIDC to one degree or another, whether with native support or third-party plugins.

Mischief Configurations Managed

Configurations get out of sort, and quickly, when:

  • more than one person edits/adds integrations to the server, or
  • you fail to follow a standard operating procedure.

To that end, we strongly mention having a formal procedure in place (and documented, see below) for when an integration is built.

This doesn’t necessarily mean that you have to use git to manage configuration files and build a review process with PRs and commits to the production repo – not that that’s a bad idea 😉 – but what it does mean is that you follow simple things like:

  • Ensure that configuration file changes are commented, with an indication of who made the change, why they made it, and when. (For example, when I’m working in an IdP config file and I make a change on a users behalf I like to comment with things like:
    <!-- IDME / 2020-01-20 / New service added. <kellen@idmengineering.com> -->
  • Make a copy of all configuration files before you make changes, and make sure they’re dated… I can’t tell you how many times I’ve seen “relying-party.xml”, “relying-party.xml.bak”, “relying-party.xml.bak2”, and “relying-party.xml.broken” all in the same config directory. Without context in the files, they’re useless.
  • Don’t be afraid of deleting extra files that come with the software packages that aren’t needed after an initial deployment… I’m looking at you and your .dist files Shibboleth.

Documentation Prevents Problems

Do you have a single, centralized list of all of your SP integrations? Does that list come along with contact info for both the local responsible party as well as the vendor? Do you have metadata and/or testing URLs readily available?

Do you have a document that you provide to integration partners that specifies what information that you expect them to provide? Don’t be afraid to be a bit demanding here. SSO is difficult. You’ll help the partner organization improve by asking them to stick to standards and give you proper details.

Federate!

How many individual metadata files are you consuming? Can you limit the number of individual relying parties that you need to add by Federating with entities like InCommon or REFEDs.


Thanks for joining us!

Just following SOME of these tips will make your life managing an SSO support environment.  It’s been a bit of an adventure, and we hope you’ve enjoyed this series.  If you need support for your SSO environment we’re here for you. IDM Engineering is a team of dedicated, honest SSO support engineers that are readily available to help you architect a new single sign on environment, manage or improve existing SSO infrastructure, or just dig in and quickly solve a integration issue. We speak SAML… and OAuth… and ADFS… and SimpleSAMLphp… and more. Furthermore, we have a carefully curated collection of technological experience and expertise that can assist you with whatever single sign-on issue you’re facing. Give us a shot! Let us know how we can help you today!

† Or — how I learned to stop worrying and love XML.

Configuring SimpleSAMLphp Logging

Configure SimpleSAMLphp Logging

Configuring SimpleSAMLphp Logging

Unfortunately, the SimpleSAMLphp documentation is a bit lacking in this area, so I thought it would be useful to document how to configure the various logging options with SimpleSAMLphp. Since SSP is actively maintained, it's worth noting that this document was prepared with SimpleSAMLphp 1.17.7 which is likely to NOT be the latest version available, even though it is at the time this document was created.

Note: All files will be referenced with respect to $SSP_DIR which in a typical install is /var/simplesamlphp:

Logging to Files

By default, SimpleSAMLphp comes with the syslog facility enabled in $SSP_DIR/config/config.php at the NOTICE level:

'logging.level' => SimpleSAML\Logger::NOTICE,
'logging.handler' => 'syslog',

However, this is not so convenient for practical debugging, where you most likely want to log to files, in this case you should specify:

'logging.handler' => 'file',

in which case SSP will write logs to the file simplesamlphp.log in the directory specified earlier within the same configuration file:

'loggingdir' => 'log/',

which defaults to $SSP_DIR/log.

Rotation

SimpleSAMLphp won't automatically perform rotation of the simplesamlphp.log file... so you must do it manually with a tool such as logrotate. For a quick example, after installing logrotate if you add the following to /etc/logrotate.d/simplesamlphp:

/var/simplesamlphp/log/simplesamlphp.log {
  daily
  missingok
  notifempty
  copytruncate
  dateext
  rotate 30
}

The logfile /var/simplesamlphp/log/simplesamlphp.log will rotate daily for 30 days.

Looking for support for SimpleSAMLphp? Look no further! Contact us for all of you SSO support needs!

SSO Support for Busy IT Admins 4 — Monitoring

SSO Support for Busy IT Admins 4 — Monitoring

So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?

This post is the fourth in five-part series on the Fundamentals of SSO Support for IT Administrators. You can see our first post here, our second post here, and our third post here, and our final post here.

Keeping Tabs on Your SSO Environment

A proper monitoring regime really gives you two – separate but equally important – tools:

  • You’ll more quickly be able to access critically important debugging information when new, unexpected errors arise.
  • You’ll be able to generally keep apprised of what’s going on… i.e. pro-actively tackling issues before they become serious, or more likely, start to gather the attention of users.

Let’s discuss each, in turn.


Know Your Logs

You would be surprised how many technical leads we encounter on a day-to-day basis that either don’t know what information is logged where, or don’t know how to properly tune their logging to get the information that’s relevant to the problem at hand.

My apologies if this post is somewhat Shibboleth-specific, as by it’s nature those products (SP and IDP) seem to obfuscate the logging process somewhat, and for the uninitiated, it can be quite daunting to determine what to long and where it’s controlled. This is further complicated, for example within SP on Windows, by how the Shibboleth Services interact with the web-browser of note. For example… if you’re leveraging Shibboleth SP on IIS, do you know what’s written to shibd.log vs. native.log. And importantly, do you know how to configure native logging properly to a file so that you don’t have to deal with Event Viewer?

It’s fundamentally important to understand what data you’re logging and have access to if you are tasked with providing SSO Support for your organization.

In SSO it’s quite rare that there are problems that result in no useful logging information. And when that does occur, 90% of the time it implies that the issue isn’t on your end, but on your integration partner’s end. The remaining 10% are usually the result of not having the correct logging categories enabled.


Being Proactive

A properly deployed environment will have at least some degree of monitoring involved. This doesn’t necessary mean deploying a full monitoring solution like Nagios, Graylog, or Splunk. More importantly, a simple audit of the logs on a normal cycle (weekly? monthly? when you can remember it?) is better than nothing.

Here, I find logging to files more useful, as you’ll be able to pretty quickly determine what’s an error that we should concern ourselves with – i.e. a particular metadata feed URL randomly dies – versus a warning we can safely ignore – i.e. a user hitting the back button at the wrong time resulting in a stale session warning.

Whatever your SSO environment looks like, take time to familiarize yourself with what is – and isn’t – logged:


Next time… SSO Management Best Practices

We’ll dive into best practices for managing integrations in your environment… what information you should require, to sign or not to sign, and why a good documentation bundle can save you a TON of headaches.

 

† Or — how I learned to stop worrying and love XML.

SSO Support for Busy IT Admins 3 — Finding Help When You Need It (Desperately)

SSO Support for Busy IT Admins 3 — Finding Help When You Need It (Desperately)

So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?

This post is the third in five-part series on the Fundamentals of SSO Support for IT Administrators. You can see our first post here, and our second post here. Our fourth post can be found here, and our fifth post here.

Master the Art of Google-Fu

Quick! Something is broken. An obscure error message fills your screen when you try to log in. Who ever is going to help you?!

It's a bird, it's a plane, it's a powerful heuristic search engine!!! Duh duh duhhhhhh!

It’s a bird, it’s a plane, it’s…
a powerful heuristic search engine!

A powerful discriminator between those who provide SSO support well, and those that don’t, is the ability to effectively search out solutions to one’s problem. In 99% of cases, whatever issue you’re encountering that you need to fix.

Here are some quick tips to make your searches more fruitful:

  • Use quotation marks. Searching for "shibboleth" log file location will be more likely to give you good results than shibboleth log file location
  • Use minus signs liberally to restrict keywords: "shibboleth" sp -idp will limit your results to only Service Provider content (ideally)
  • Search specific sites using a colon: shibboleth sp site:wiki.shibboleth.net to search the Shib wiki using Google
  • Search sites that link to a particularly useful resource for explanatory content, i.e. best practices link:wiki.shibboleth.net
  • Try using Google Advanced Search

For more advanced search operators, see: Google Advanced Search Operators: The Ultimate List (40+ Advanced Operators)

Get Help from Others

Okay, Google hasn’t been that helpful. It’s not a miracle cure for all of your SSO Support needs. Maybe it’s pointed you in a couple of directions, but you’re still unsure. No worries… everyone has been there. Which is why, during your searches, you should have encountered tons of resources for where to ask your unanswered questions.

These can be more or less helpful, depending upon the community, who frequents it, who answers questions, and perhaps most importantly… how you ask the questions. Never post to a forum:

ADFS won’t work. What do?! Error -2146885613

Because you’re NOT going to get anything from that. To give you insight into what makes a good question on ANY forum or mailing list, take a look at the StackOverflow guide to asking questions.

Here are some good places to keep in mind for getting help:

Get Help From a Professional

We’d be remiss to not mention ourselves here. If you’re really struggling with a problem, and none of the above have helped, we’re here.

IDM Engineering is a team of dedicated, honest SSO support engineers that are readily available to help you architect a new single sign on environment, manage or improve existing SSO infrastructure, or just dig in and quickly solve a integration issue. We speak SAML… and OAuth… and ADFS… and SimpleSAMLphp… and more. Furthermore, we have a carefully curated collection of technological experience and expertise that can assist you with whatever single sign-on issue you’re facing.

Give us a shot! Let us know how we can help you today!


Next time… Keeping Tabs on Your SSO Environment

We’ll dive into best practices for monitoring your environment… keeping tabs on your servers, looking for problems before they occur, and conducting regular maintenance will help your future self not hate single sign-on so much!

† Or — how I learned to stop worrying and love XML.

SSO Support for Busy IT Admins 2 — THE LAB

SSO Support for Busy IT Admins 2 — THE LAB

So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?

This post is the secondof a five-part series on the Fundamentals of SSO Support for IT Administrators. You can see our first post here, our third post here, our fourth post here, and our fifth post here.

The Lab is Your BEST Friend

No matter what issue you’re facing when it comes to SSO, if you can’t dive into an environment that’s almost like your production environment and mess everything up trying to make something happen, you’ll never be able to manage SSO support for your organization. And there are countless tools, like Docker and Git, that make keeping a lab environment a breeze.

The Lab Should Be Production Lite

If you’re responsible for a load-balanced Shibboleth and CAS dual-deployment environment with two-nodes for each, then no, you don’t NEED to have 4 more server VMs running for the lab. But in that kind of case, it’s entirely reasonable to keep a dev CAS and a dev Shibboleth instance on hand, separated in the same way they are separated in production, but simply not load balanced.

Likewise, if your production server runs on an AWS t2.2xlarge doesn’t mean that a t2.micro wouldn’t suffice. If you’re leveraging a cloud provider resource like AWS already, there’s no reason that you can’t keep your dev instance spun down (but NOT terminated) effectively indefinitely.

Furthermore, when it comes to SAML, the single most important bit of information is the entityID. You can have a dev Shibboleth IDP for example, which is configured with the same entityID as your production environment. Then, so long as you point the DNS hostname of the production IdP to your dev server’s IP address, authentications will occur against that box. That means it’s relatively trivial to test configuration changes (like attribute release policies) BEFORE moving the configuration to production.

Don’t Be Afraid to Break Things

I use git to manage my configs on all of my dev environments which utilize file-based configurations. (Others prefer subversion.) Every time I want to make a new major change (say, experiment with a new, custom MFA provider in Shibboleth) I’ll create a new branch. That way, if I need to, I can just checkout the last working branch and all of my work is still safe and sound in the “indev” (as I like to name them) branch.

Here’s another use case… let’s say you’re responsible for idp.example.org, a Shibboleth IdP. You need to work on onboarding two service providers, Company A and Company B. You can work on these configurations separately within two branches, without worry that changes you make for Company A will throw things off for Company B’s integration. As the integrations start to near completion… you merge the branches separately.

If you’re also leverage git for production, when you’re ready to push the configs live, it’s just a matter of a simple git push to the relevant remote and a restart of Shibboleth (or a call to a reloadable service)

Similar functionality can be achieved in the ADFS / Windows sphere with Virtual Machine Snapshots and Powershell, though that’s inherently a bit trickier.

Next… To the Internet!

Next week… we’ll dive into the standard first action you should always, ALWAYS taken when confronted with a new issue: GOOGLE THE HECK OUT OF IT!


Can’t Wait?

Need help now? Well what would a blog post be without a sales pitch? IDM Engineering is a team of dedicated, honest SSO support engineers that are readily available to help you architect a new single sign on environment, manage or improve existing SSO infrastructure, or just dig in and quickly solve a integration issue. We speak SAML… and OAuth… and ADFS… and SimpleSAMLphp… and more. Furthermore, we have a carefully curated collection of technological experience and expertise that can assist you with whatever single sign-on issue you’re facing. Give us a shot! Let us know how we can help you today!

† Or — how I learned to stop worrying and love XML.