I am often asked about support for “Realm Stripping,” albeit mostly by those in the university space. It’s an interesting concept, certainly. The idea is that someone will issue an identity that includes some “routing” information within the identity. For example, a user may issue a username of: firstname.lastname@example.org. From that username, the RADIUS server should be able to strip out the username “johndoe” and use the “@somedomain.com” to specify the identity store to query for the username and password.
Think about it. It would allow federation of identity in a pretty clean way, because my domain name is included as part of my username, and therefore your RADIUS server would be capable of asking my identity store to validate the user or not.
eduroam is one of the most popular services for this type of routing. This service allows students to roam from university 1 to travel to university 2’s campus for the day and authenticate to University 2’s wireless network using their credentials from their original University’s credentials.
A requirement to support the Eduroam service is that a RADIUS server must be able to strip off the routing data (called a “realm”). So email@example.com authenticates to University 2’s network, the identity request is routed to the Eduroam service which sends the request to University 1’s RADIUS server. That RADIUS server must be capable of stripping the @universityX.edu from the identity, so the true username of “johndoe” is used in the query against their identity store (AD, PeopleSoft, whatever may hold the actual credentials).
Pretty cool, huh? I always thought so, but it was something that Cisco ISE only had VERY limited support for until recently. ISE always had the ability to strip realms when using RADIUS-Proxy servers for the identity store – but only the “outer-identity” (sometimes called the “anonymous identity,” which is a total oxymoron) was stripped off, leaving the inner-identity alone. This was problematic, because trying to teach a million students who “just want network access” how to configure their outer identity with so many supplicant variations in their devices was not exactly administratively lightweight. ISE also supported this for LDAP connections, which had the capability to strip both the inner and outer identities, but often that was not adequate.
There was a “hidden gem” released in ISE 1.2 patch 5 that includes Real Stripping natively! Wahoo! Thank you Cisco ISE Network Access team, and (of course) the ever persistent Serviceability Product Owner who keeps pushing these great ideas (inside joke, sorry for those of you who don’t get it).
To top it all off, ISE even has the ability leverage the information that was stripped out as an attribute that factors into the Authorization Policy, so that information may still provide value with the access decision. Plus, it’s all pretty easy to configure. Let’s take a look at an example:
Realm Stripping Configuration Example
In the example above, I’ve shown the stripping of some prefixes, as well as suffixes. Multiple entries are separated by commas. Note: in ISE 1.2 patch 6 the product will also strip out erroneous spaces between the entries, but with patch 5 you must ensure you do not have spaces included.
In the figure above, we are stripping the following Prefixes: “dom1\,dom2$,dom3” which will yield the following results:
dom1\brad becomes brad
dom2$brad becomes brad
dom3brad becomes brad
We are also stripping out the following Suffixes: “@domain.com,@domain2”
firstname.lastname@example.org becomes suzy
email@example.com becomes suzy
There are a number of use cases for Realm Stripping. You could use it to separate lines of business, or possibly just to replace an older-legacy FreeRADIUS system that used Realms to allow the end user to influence authorization results. While the latter is not a design I would ever recommend, I have had to work with companies that require the functionality in order to upgrade their legacy systems to a more modern policy server, like Cisco’s ISE.
Well that’s it for now, keep checking back for more!
This article is published as part of the IDG Contributor Network. Want to Join?