Session 1175: "IBM Notifier: Oh wee what up with that"

For those unfamiliar with IBM Notifier, Jonathan Krauer, Engineering Lead, Mac@IBM provides a brief description of the software product:

“IBM Notifier is a fully customizable notification tool that can fit nearly any need when it comes to providing information to your employees or customers.”

He goes on to give some background about IBM Notifier’s customization capabilities, such as the various types of pop-ups and banners available, among others that help to not only address your unique needs but do so as a natural extension of macOS.

Alongside the presentation, Krauer includes two demonstrations:

1. How to implement IBM Notifier, so that it looks like a product that fits in with your organization.
2. Novel approaches to handling frequent notifications that provide the end-users agency with how to manage their Mac.

How do I obtain IBM Notifier for my environment?

To facilitate getting started and making the process as easy as possible, Krauer provides a QR code and URL to IBM’s GitHub repo, along with guidance as to how to begin deploying IBM Notifier to your environment.

Should you wish to modify it to better suit the needs of your organization, the download is available as a binary file or source code. Additionally, there are code samples to get IT admins well on their way.

Lastly, he also includes a link to the JNUC 2021 presentation where IBM Notifier was introduced, which includes a few scripting ideas for those that missed last year's presentation or simply wish to maximize their success in deploying IBM Notifier within their environment.

But, can I customize IBM Notifier?!

Grant Klingbeil's, Sr. Manager, Mac@IBM, portion of the presentation, he takes on — you guessed it — customizing IBM Notifier for your environment, and what is needed to get started.

Klingbeil explains that, before diving in, there are a few necessary requirements to have in place in order to successfully customize their software... namely:

• IBM Notifier project downloaded from GitHub
• Apple Xcode (or your preferred IDE)
• Apple Developer Certificates

Klingbeil goes on to say that, with all the pieces in place, the entire process to build the app for your environment should not exceed fifteen minutes. As he goes on to show during the demo process, once completed, the app will be built, signed and notarized for your environment.

The duration of the presentation includes the aforementioned presentation, handled by Krauer, providing interesting takes and novel approaches to managing notifications for a number of different situations, including sample code examples, which can be downloaded by way of a third QR code presented at the end of the presentation.

Session 1176: "Modernizing authentication practices to Jamf Pro APIs"

Jamf Pro offers two Application Programming Interfaces (API) to choose from when setting up integration with third-party software and is the “secret sauce” used when automating tasks within the Jamf Pro system and targeting devices managed by the MDM solution.

• Jamf Classic API
• Jamf Pro API

As Patrick Norton, Sr. Platform Engineer, Mac@IBM briefly shares the fundamentals of the API interface and touches upon how the two are different. An example of the differences includes support for commands that may be performed may only be present in the newer Jamf Pro API compared to the Jamf Classic API.

A change cometh…

With the impending change from Classic to the newer, more secure token-based authentication process, Patrick lists some of the things IT admins should be aware of when preparing to successfully make the switch within their organization:

• Prepare scripts to switch to tokens
• Assess which APIs calls are used for compatibility
• Make note of how frequently scripts run
• Decide on where and how to best store tokens

He also covers other components that are used within the organization, including but not limited to PHP Webhook Receivers, Python Processing Scripts and MySQL Database. It’s important, as Patrick highlights, to make a note of these components and how they integrate within the larger device management paradigm so as to not inadvertently “break” compatibility with existing software being used within your organization when making changes to scripts and/or switching to token-based authentication.

API Authentication Methods

We’ve heard about the new API and what switching to token-based authentication entails. At this point in the presentation, Jan Valentik, Software Developer, Mac@IBM discusses the various authentication methods used by API. Specifically, Jan mentions each method alongside how they work and their impacts on security and resources:

• HTTP basic authentication: Base64-encoded credentials are sent to the server each time a connection attempt is required. Every time a request is made, the server must check if the account exists and if the password is correct, which utilizes greater resources. Additionally, this method does not scale very well in cloud-based environments, requiring each microservice to perform its own authentication, which further burdens resources.
• API access tokens: Token-based authentication is easier for servers to process (i.e., use fewer resources) as it doesn’t require account lookup in directory services. Furthermore, once authentication occurs successfully, users are granted the API key and, with it, access to the entire API without limitation or requiring further authentication requests. This also adds a security concern since anyone with the API key could theoretically gain access to the API without further challenge.
• OAuth with OpenID: Lightweight method that offers the best of both worlds. It does not require server lookups upon each request as the OAuth token carries the authentication data within it, plus this offers the security of expiration after a period of time. It also scales quite well in cloud-based environments.

Switching from basic to token-based authentication

For the final portion of this session, Noor Jabaieh, Platform Engineer, Mac@IBM, explains and demonstrates the process of transitioning to token-based authentication.

Jabaieh details how bearer tokens work: akin to bearer bonds in the financial world, but in this case, referring to a machine-generated cryptic string that first requires the user to send a request to the API. The request includes authenticating the user’s credentials. Once successfully authenticated, a JSON object will be generated by the API, along with the token itself and its expiry date.

She also details some of the features of token-based authentication, such as:

• Being stateless, containing everything needed within
• Not being resource intensive on the client or server, making them lightweight
• A set thirty-minute expiry, making them invalid after the timeout
• Invalidating unnecessary tokens using the invalidate-token endpoint command

Before returning to Norton for a demonstration of various features, including how to invalidate a token, Jabaieh touches upon several extremely useful and valid points for IT admins to bear in mind when deciding to transition to token-based authentication:

• Token-based auth was introduced to Classic API in Jamf Pro 10.35. Cloud-based customers will not have to worry about support, but on-premises customers using Jamf Pro versions older than that version will need to upgrade before they can make the jump.
• Basic auth is set to be fully deprecated later in 2022. Something to consider when meeting with other teams to discuss the deployment plan and subsequent rolling out of this feature or simply to be aware of the cutoff deadline.
• Prepare your environment. Alongside the planning phase, assessing your environment and organization's needs, the preparation of your environment is a necessary part of the transition to token-based authentication. By ensuring that scripts, Jamf integrations and specific needs unique to your organization are addressed prior to transitioning, IT admins can minimize the potential for loss of access or other issues related to the transition process.