Category Archives: Blog

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:

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.

This entry was posted in Blog, SSO Support Guide and tagged guide on January 6, 2020 by idme.

Configuring 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.

Note: you will want to ensure that any directory that you specify for the loggingdir has the proper file system permissions. The service account under which your webserver runs will need read, write, and execute permissions for this directory. Since that account typically already owns the loggingdir this is usually just a simple matter of: chmod u+rwx if you notice that no logging data is being written to the specified directly.

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!

This entry was posted in Blog, SimpleSAMLphp on December 31, 2019 by IDM Engineering.

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:

Shibboleth SP Logging
Shibboleth IdP Logging
SimpleSAMLphp Logging — unfortunately, documentation here is sparse. One line under Maintenance. (Look for a future post from us concerning the topic. Will update this post when available.)
ADFS Logging

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.

This entry was posted in Blog, SSO Support Guide and tagged guide on December 30, 2019 by idme.

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!

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:

Shibboleth Users Mailing List (though there are better options for SSO Support for Shibboleth Consortium Members)
Microsoft ADFS Technet Forum
SimpleSAMLphp Google Group
The StackOverFlow single sign-on Tag
Forums/channels related to your particular OAuth library, i.e. the PHPLeague OAuth2 Client Gitter

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.

This entry was posted in Blog, SSO Support Guide and tagged guide on December 17, 2019 by idme.

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.

This entry was posted in Blog, SSO Support Guide and tagged guide on December 6, 2019 by idme.

SSO Support for Busy IT Admins

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 first of a five-part series on the Fundamentals of SSO Support for IT Administrators.† You can see our second post here, our third post here, our fourth post here, and our fifth post here.

SSO Support Doesn’t Have to Be Hard

You wouldn’t necessarily know this by researching “best practices”. Trying to find information about best practices for managing a Shibboleth environment, for example, will turn up a lot of lackluster information. For example, a brief inquiry on “managing a Shibboleth IdP environment” turns up some basic Shibboleth Wiki entries, a ton of integration instructions for getting popular Service Providers working with Shibboleth, and the only truly reasonable resource that turns up on the front page is an excellent, though aged whitepaper: “Implementing a Shibboleth SSO Infrastructure” from SANS.

So what are you to do?

Start Small: First Principles

Ask yourself this? Can you explain how a single sign-on interaction works? Can you explain it to your mother? What about a rubber duck? If the answer to any of these questions is “no”, perhaps it’s time to take a step back and assess your knowledge.

What technologies does your environment leverage? SAML? ADFS? OAuth? Make sure you’re familiar with the concepts of single-sign on before trying to dive in to a Shib IdP config and get MFA working.

For SAML —

The shib wiki isn’t a bad place to start here, surprisingly, but you should relatively quickly realize that Shibboleth != SAML. OASIS is the group that actually oversees that SAML protocol, and the high-level overview that they provide is a fantastic place to start if you don’t “get” SAML.

For ADFS —

You are, unfortunately, subject to the whims and whimsy of The Great Old Ones in charge of Microsoft. Fortunately, there is some good documentation to come out of Redmond, such as this piece on best-practices when deploying ADFS. They’ll even helpfully tell you that it only takes 9 minutes to read (do not misconstrue reading and understanding). Getting used to the nomenclature surrounding ADFS can be a bear — ADFS has it’s own language — though you’ll be able to go a long way if you just substitute “identity provider” every time you ready “claims provider” and “service provider” each time you read “relying party”.

For OAuth —

First thing first: do you understand that OAuth 1.0 ≠ Oauth 2.0 ≠ OpenID Connect ≠ OpenID? Here StackOverFlow provides! This new-ish technology (for the IAM community) has an abundance of posts on how it’ll solve all of your problems, but adoption at the enterprise is slow, which means that it can be a challenge to find trusted sources. What’s left then are commercial providers. Here, Auth0 takes the lead in providing a reasonable trove of materials.

Next… To the Lab!

Next week… we’ll dive into the crucible by which Help Desk turn into Engineers, the lab, and why development environments play an absolutely crucial role for those tasked with SSO Support for their Organization.

Can’t Wait?

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

This entry was posted in Blog, SSO Support Guide and tagged guide on November 26, 2019 by idme.

Configuring native.log for Shibboleth SP3 on IIS

Configuring native.log for Shibboleth SP3 on IIS

One of the complaints we receive the most from clients utilizing Shibboleth Service Provider (SP) on Windows Server / IIS, is that native.log is empty or missing.

This log, while under typical operational loads is generally indistinguishable in its content from shibd.log, the native logger provides valuable information about internal request mapper routing. This can vary from unimportant, to relevant, to absolutely critical information when it comes to diagnosing SP issues.

On Windows systems, the default native logging is to the Windows Event Log, which is observable with the Event Viewer (under Application and Services Logs -> Shibboleth).

The following configuration snippet is taken from the distributed native.logger file, and configures the log4j (logging provider for Shibboleth) appender for the Event Viewer:

log4j.appender.native_log=org.apache.log4j.NTEventLogAppender
log4j.appender.native_log.source=Shibboleth Service Provider
log4j.appender.native_log.layout=org.apache.log4j.PatternLayout
log4j.appender.native_log.layout.ConversionPattern=%c %x: %m

org.apache.log4j.NTEventLogAppender triggers the logging to the Windows Event log. You can adjust the other parameters of this logging here if you are content with this behavior.

To get more ‘natural’ behavior, you can instead define the following appender in native.log

log4j.appender.native_log=org.apache.log4j.RollingFileAppender


log4j.appender.native_log.fileName=C:/opt/shibboleth-sp/var/log/shibboleth/native.log

log4j.appender.native_log.maxFileSize=1000000


log4j.appender.native_log.maxBackupIndex=10

log4j.appender.native_log.layout=org.apache.log4j.PatternLayout

log4j.appender.native_log.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S} %p %c %x: %m%n

and Shibboleth will write this information into the native.log file of your specification. This is the default behavior on Linux-based installs, but isn’t done on Windows because this alone is insufficient. You must also ensure that the file you want Shibboleth to write to is given writable by the IIS service account, IUSR:

The above screenshot demonstrates the permissions that we utilize on one of our dev IIS servers which is writing logs to native.log.

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

This entry was posted in Blog, Shibboleth on November 20, 2019 by IDM Engineering.

LDAP SSL/TLS Config for Shibboleth IdP

LDAP SSL/TLS Config for Shibboleth IdP

Many (if not most) of our clients utilize LDAP as the authentication source for Shibboleth IdP.

That said, we all too often encounter environments without properly configured encryption of the connection. All-to-often this arises because of uncertainty about the options and how to properly configure SSL/TLS for the IdP.

Shibboleth supports two mechanisms for encrypted connections:

TLS

The most basic connection is TLS (transport layer security). Confusingly, this is usually referred to in logs and configs as SSL (even outside of Shibboleth), but does not refer to true SSL by itself. As a protocol, SSL has long been deprecated, but we still use the term colloquially to refer to TLS.

The Shibboleth configuration options (in the ldap.properties file) for TLS look something like this:

idp.authn.LDAP.ldapURL       = ldaps://ldap.example.org:636
idp.authn.LDAP.useStartTLS   = false
idp.authn.LDAP.useSSL        = true

We’ve set idp.authn.LDAP.useSSL to true to indicate that our IdP is to connect via TLS (I know, it’s silly nomenclature), and our ldapURL includes both the protocol specification as ldaps:// and the port number that’s typically used for LDAPS connections (TCP/636).

Start TLS

The second connection type is called StartTLS. In this mode, the connection starts out as clear text communication over the standard port (TCP/389), during which the IdP indicates to the LDAP server that it should communicate via a secure connection. It’s at this point that TLS negotiation occurs, and afterwards communication is secure.

The configuration in Shibboleth looks like this:

idp.authn.LDAP.ldapURL       = ldap://ldap.example.org:389
idp.authn.LDAP.useStartTLS   = true
idp.authn.LDAP.useSSL        = false

Note that the major differences are that we’ve explicitly flagged to use StartTLS as opposed to SSL, and the LDAP URL includes the non-secure port number (TCP/389) as well as a regular ldap:// protocol identifier.

There are advantages to either choice. StartTLS can make networking firewall rules simpler, but not all LDAP deployments support it, and so it’s not a universal mechanism.

What’s important is that it doesn’t matter which mechanism you choose, so long as you do choose one.

No matter how secure you think the internal network is between the IdP server and the LDAP server, you don’t want to trust the data between the two traveling in the clear.

This entry was posted in Blog, Shibboleth on November 8, 2019 by IDM Engineering.

Releasing NameID with a Specified Format

Releasing NameID with a Specified Format

A frequent task for ADFS Identity Provider administration is onboarding a new Relying Party Trust and releasing to that relying party a particular set of attributes. Frequently, service providers will request a particular attribute take the form of a Name Identifier (NameID), formatted accordingly.

Name Identifiers are special attributes that come within the SAML <subject> element. For example,

<Subject>
    <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      user.name@idmengineering.com
    </NameID>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_31dde5dfce9c812303ed02d73fb382e9"
                                 NotOnOrAfter="2019-11-06T18:41:11.977Z"
                                 Recipient="https://sp.example.com/SAML2/POST" />
    </SubjectConfirmation>
</Subject>

Here, I’ve released an email address for my user with the format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. Let’s re-create the above SAML response <subject>.

Example: E-mail Address as NameID

For the remainder of this discussion, we’ll assume that you’ve configured a claims-aware relying-party trust within ADFS. We now want to configure a NameID to be released from a particular LDAP attribute. Here’s how we’ll achieve the above result with ADFS.

Note: These instructions should work for ADFS 2.0 and up.

From the ADFS Management Console, select Trust Relationships > Relying Party Trusts.
Highlight the relying party which you are trying to configure, and under Actions on the right hand side pane, select Edit Claim Rules.
Click Add Rule.
The default claim rule template is Send LDAP Attributes as Claims so you should select Next.
Give the rule a meaningful name. We’ll first be establishing a claim that we can later use to release the attribute with a particular format, so I’ve chosen to call this rule “Make Email Address Available for NameID“.

Select your attribute store, which will most likely be Active Directory.
Select the attribute that you wish to release as the NameID. Here I will select Email Addresses.
And select the outgoing claim type as E-mail Address.

Note: Do NOT select Name ID as the outgoing claim type here if you wish to specify the format. Selecting this will send the user’s name address as the Name ID, however, there will be no formatting information, i.e. <NameID>user.name@idmengineering.com</NameID> would appear within the <subject> element of the SAML Response.

Click Finish.
Now, we’ll add a rule to Transform that claim into a properly formatted NameID. Select Add Rule once more from the Edit Claim Rules dialog.
And this time, change the Claim rule template: drop-down to Transform an Incoming Claim, then select Next.
Once again, give this rule a meaningful name, like “Transform Email to NameID“.
Select as the Incoming Claim Type whatever claim you chose to issue in the previous rule. In this case, that’s E-Mail Address.

Select Name ID as the outgoing claim type.
And now, you can specify the Name ID Format that you wish to use. The following table lists the Outgoing Name ID Format selections available within ADFS, and the corresponding format identifier URI that will appear within the SAML <subject>.

Outgoing NameID Format	Format Identifier URI
UPN	http://schemas.xmlsoap.org/claims/UPN
Email	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Common Name	http://schemas.xmlsoap.org/claims/CommonName
Unspecified	urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
X.509 Subject Name	urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
Windows Qualified Domain Name	urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
Kerberos Principal Name	urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
Entity Identifier	urn:oasis:names:tc:SAML:2.0:nameid-format:entity
Persistent Identifier	urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
Transient Identifier	urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Bold entries represent the most commonly requested formats.

Cautionary Note About urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

The urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified format is unique. Formally, this is what the Service Provider should list within their metadata if they do not care what Name ID Format an IdP uses. In practice, however, many IdP administrators assume that this specification in an SP’s metadata means that they are REQUIRED to release a NameID in this format. This is not the case.

It is because of this assumption, however, that ADFS allows one to release a Name ID in this format.

Persistent vs. Transient -or- Welcome to SAML 2.0

For a good discussion of the concepts behind Name Identifiers, see this post from the Shibboleth Wiki. In particular, name identifiers have a number of characteristics which define them, including:

Persistence – whether a given name id is intended to be used across many sessions.
Revocability – whether a given name id can be revoked.
Re-assignability – whether a given name id, once revoked, may be reassigned to a different subject.
Opaqueness – whether a relying party can positively identify the subject from a given name id.
Targetability – whether a given name id is intended for a specific relying party.
Portability – whether a given name id is usable across security domains.
Global – whether a given name id value is globally unique.

The SAML 2.0 spec therefore defines two primary formats:

Type	Characteristics
Persistent	A persistent, revocable, re-assignable, opaque, targeted and portable identifier.
Transient	A non-persistent, non-revocable, opaque, non-portable, non-targeted, global identifier.

which broadly encompass the whole of these Name IDs, and provide a broad basis for (importantly) opaque identifiers. Both NameIDs result in hashed values being sent, but one will always be different for every user and every session (transient), and the other will always be consistent for a given user and service. But importantly, neither will be easily associated to a given user based only on the Name ID value.

This entry was posted in ADFS, Blog on November 6, 2019 by IDM Engineering.

Configuring Reloadable Services for Shibboleth IdP

Configuring Reloadable Services for Shibboleth IdP

Shibboleth Identity Provider Version 3 introduced the ability to reload individual services within the Shibboleth framework. Prior to IdP v3, if you wanted to onboard a new Service Provider by adding new <MetadataProvider> and <RelyingParty> elements, you would be required to restart the servlet container. Now, nearly every class of change that you may need to make to the Shib IdP can be done without restarting Jetty.

Reloadable Services

There are two functional methods to achieve this, either a direct request to the administrative handler URL:

http(s)://idp.example.org/idp/profile/admin/reload-service?id=[SOME SERVICE]

or by utilizing the included sample shell script which will make this call for you:

$ /opt/shibboleth-idp/bin/reload-service.sh -id [SOME SERVICE]

In each case [SOME SERVICE] represents the name of the Shibboleth service that you would like to reload, i.e. one of the service identifiers (id) listed below.

Access Control

In order to be able to make requests to the reloadable services identified above, you must ensure that you have white-listed the IP address of the host making the call. In the case of the reload-service.sh script, that includes ensuring that the interface of the IdP server itself has been whitelisted.

To do this, ensure that the IP addresses are listed within /opt/shibboleth-idp/conf/access-control.xml as in the following example:

<entry key="AccessByIPAddress">
    <bean id="AccessByIPAddress" parent="shibboleth.IPRangeAccessControl"
        p:allowedRanges="#{ {'127.0.0.1/32', '::1/128'} }" />
</entry>

Services

The following services can be reloaded:

Reloadable Service `id`	Function
shibboleth.RelyingPartyResolverService	shibboleth.ReloadableCASServiceRegistry
shibboleth.MetadataResolverService	MetadataConfiguration resources.
shibboleth.AttributeResolverService	AttributeResolverConfiguration resources.
shibboleth.AttributeFilterService	AttributeFilterConfiguration resources.
shibboleth.NameIdentifierGenerationService	NameIDGenerationConfiguration resources.
shibboleth.ReloadableAccessControlService	AccessControlConfiguration resources.
shibboleth.ReloadableCASServiceRegistry	Resources containing ServiceRegistry beans to be reloaded.

Example: Onboarding a new SP

In the following examples, we will only use reload-service.sh, however you can easily adjust the call to the HTTP GET as above.

After you’ve added the SP’s <MetadataProvider> element to /opt/shibboleth-idp/conf/metadata-providers.xml you should first reload that service:

[root@idp.example.org shibboleth-idp]# ./bin/reload-service.sh -id shibboleth.MetadataResolverService

Configuration reloaded for 'shibboleth.MetadataResolverService'

Then, after you have added an appropriate attribute filter policy for this entity in attribute-filter.xml, you should reload that service:

[root@idp.example.org shibboleth-idp]# ./bin/reload-service.sh -id shibboleth.AttributeFilterService

Configuration reloaded for 'shibboleth.AttributeFilterService'

Lastly, presuming you need to configure a <RelyingPartyOverride> for this entity to adjust the particulars of the single sign on integration, you should reload that service:

[root@idp.example.org shibboleth-idp]# ./bin/reload-service.sh -id shibboleth.RelyingPartyResolverService

Configuration reloaded for 'shibboleth.RelyingPartyResolverService'

Common Issues

The most common issue we encounter with reloadable services is that calls to reload-service.sh fail, either because Access Control was not established properly, or because the IDP cannot properly make calls to http(s)://localhost/idp which is the default IDP_BASE_URL environment variable.

Setting up IDP_BASE_URL within your Shibboleth service’s startup (typically /etc/default/jetty) script usually resolves this issue. For example, a typical startup script might need to look something like this:

export INST_BASE=/opt
export JAVA_HOME=$INST_BASE/java
export JAVA=$JAVA_HOME/bin/java
export JETTY_HOME=$INST_BASE/jetty
export JETTY_BASE=$INST_BASE/idp_jetty
export IDP_HOME=$INST_BASE/shibboleth-idp
export IDP_BASE_URL=http://idp.example.org/idp

This entry was posted in Blog, Shibboleth on October 24, 2019 by IDM Engineering.