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 & 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 (www.eduroam.org) 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 actual 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 University2’s network, the identity request is routed to the Eduroam service which sends the request to University1’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 total oxymoron) was stripped off, leaving the inner-identity alone. This was problematic, because trying to teach 1,000,000 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 & outer identities. But that often times 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:
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 their authorization results. What 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!