IAM Online Multilateral Federation Webinar participants:
University of Arkansas - Stephen Tycer, CISO, Selena Hriz, Associate CIO for Enterprise Service Management
State University of New York, Geneseo - David Warden, Senior Systems Analyst & Managing Director of Research Technology, Jack Truckenmiller, Systems Analyst
Cirrus Identity - Mary McKee, Senior Director of Engineering
During the January 17, 2024 IAM Online webinar, we were not able to address all the questions directed to Cirrus Identity and our customers during the allotted time. With many thanks to the participants, here are the follow up responses:
—------------------------------------------
Question 1: Was there research into seeing if the problem could be resolved by either proxying things from Shib over to Entra, or rather proxying federation services from Entra to Shib?
Response from UArk: UArk did originally and even looked at a third party to help out. The complexity and cost [of continuing to run Shib] made this option unpalatable.
—------------------------------------------
Question 2: It seems MS does not utilize AuthnContextClassRef. How did you handle the InCommon apps that set it? Multiple proxy apps in Microsoft?
Response from Geneseo: Are you referring to InCommon apps that require the REFEDS MFA profile? I’ll let the Cirrus folks chime in, but my understanding is that Cirrus’ Bridge product handles this for us as long as we require MFA on the Microsoft side. Geneseo may be unusual in that we tend to require MFA for all SAML apps in Microsoft Entra ID, which means we did not have to do anything to support InCommon apps that require REFEDS MFA when accessed through our Cirrus Bridge.
However, Geneseo did experience pain from Entra ID around the mechanism by which a service can request specific authentication methods via the RequestedAuthnContext element of AuthnRequest. Our users who authenticate via FIDO2 or what Microsoft calls “passwordless” methods are presented with a Microsoft error when trying to access services that specifically request password-based authentication in their AuthnRequest:
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
We have had to ask individual vendors to change or relax their AuthnRequest elements. We haven’t (yet?) experienced the reverse, where an app requests an AuthnContextClassRef stronger than “password”, and our users can’t access the app.
This feels like an area where additional conversation and engineering resources from Microsoft to provide clarity and flexibility around interpreting and responding to RequestedAuthnContext in AuthnRequests would be beneficial. Not every vendor is going to be receptive to or able to tweak those for individual customers, and I think we’ll only see greater use of RequestedAuthnContext as MFA requirements proliferate.
—------------------------------------------
Question 3: Did this require an all or nothing SP migration (big bang) or could you migrate an SP (or group of SPs) at a time…over to Cirrus SAML bridge.
Response from UArk: We used the DNS option to test out of band and then move over in one night. Outside of the App that was not working in Shib everything went very smoothly.
Response from Cirrus: The Cirrus Identity SAML and CAS Bridge implementations can utilize the DNS Add-On to move all authentication network traffic from Shibboleth or CAS to the Bridge. The benefit of this approach is that the SP metadata and the InCommon registration do not change. We also support standing up a Bridge in parallel and individually migrating SPs. InCommon currently supports having two Identity Providers registered for no extra fee for 6 months.
—------------------------------------------
Question 4: How many people worked on the project to retire Shibboleth and replace it, and how long did the project take? Any estimate of the person-hours needed?
Response from UArk: We had one tech and a PM. We also had the Cirrus team support. It was not a priority project and it took about three months because of some attribute issues. If we had been focused, I would say that three weeks would have been enough to get it done.
Response from Cirrus: Typical customers take 2 weeks for configuration and the remainder of the time for testing which can vary widely depending upon the number of SPs, campus stakeholders and other campus priorities.
—------------------------------------------
Question 5: What processes do you have in place to ensure your application inventory stays up-to-date over time?
Response from Geneseo: At least for Geneseo, having more people do application onboarding has helped refine our documentation and application inventory management; it's harder to cut corners when you know it might negatively impact your coworkers.
—------------------------------------------
Question 6: What is the License / Pricing structure for Cirrus Identity Products? How did it change the Budget/funding for your respective departments?
Response from Cirrus: There is a subscription fee for the Cirrus Identity SAML Bridge based on the number of annual authentications along with the DNS Add-On . There is also a one-time implementation fee. Most institutions find the expense less than the infrastructure costs and administrative/support labor and find benefit in having staff time to focus on other priorities. [See question #1]
—------------------------------------------
Question 7: We have complex attribute filter and resolver rules in Shibboleth IdP currently, what does the process for importing those into Cirrus identity bridge look like?
Response from Cirrus: When migrating to the Cirrus Bridge, customers generally use the native capabilities from Microsoft or Okta to reflect the legacy attribute release rules. Cirrus Identity does recommend taking the opportunity of implementing Cirrus Bridge to harmonize, streamline, and simplify your attribute release. Cirrus Customer Success has significant experience helping customers reduce complexity. Cirrus Identity has also engineered some Attribute Transformation Tools (https://blog.cirrusidentity.com/documentation/attribute-transformation-tools-for-conditional-access) to address common R&E Federation specific gaps to the native capabilities. Cirrus Identity does offer the Cirrus Attribute Authority (https://www.cirrusidentity.com/products/attribute-authority) which can be used to address some complex legacy attribute release scenarios. Lastly Cirrus Engineering can also implement custom configurations for those rare cases where there is a unique need, though there are usually additional costs associated.
—------------------------------------------
Question 8: Would you please share what type of attributes you stored in Cirrus and is it designed to store sensitive attributes? (e.g., last four of SSN).
Response from Geneseo: Although Cirrus does have access to the plain text of these attributes, they do not store them beyond caching them for the lifetime of the user’s session. In other words, their Attribute Authority system does a blocking query to our LDAP when users access an Entra ID service that needs one of these attributes. We don’t consider that to be “Cirrus stores these attributes”, but we also understand that others may feel differently. The actual attribute that led us to Cirrus’ Attribute Authority was a campus person identifier number. We restrict read and write access to this attribute to specific Active Directory security groups. There was much debate over it needing to remain protected in this way as we adopted Entra ID, but in the end we didn’t feel good about losing a security control that we had grown accustomed to.
Response from Cirrus: To further clarify, without the Attribute Authority Add-On, the Cirrus Identity SAML Bridge accesses attributes stored in EntraID and asserts them to the configured SPs. With the Attribute Authority Add-On, Cirrus can also access attributes in LDAP or another data store. In both examples, Cirrus does not store the data, but includes it in the SAML assertion.
—------------------------------------------
Question 9: What I hear is, "We can buy yet another vendor product to further move our environment away from standards, and replace what we're getting for free." What benefits do you see from having done this work? Add-ons for DNS; add-ons for the Azure environment. Violation of expectation of the ways in which these platforms natively work. I'm sure you recognize how vendor (C) will come along and expect things to work in a particular way, and these change the picture in ways that are unexpected.
Response from UArk: One of the benefits is that we have Cirrus Identity helping us. That’s an important part for us because of smaller schools being involved in this. They don’t have IT staff to manage this and we can’t manage it for them so it was a hugely important thing for us; finding someone who could help with IAM as we go forward in smaller and more diverse schools out there. Also, there is a lot of other stuff we use at Cirrus. IAM is a huge journey for us. Selena mentioned global campus which is our remote education facility at the University of Arkansas. Also, there is lots of research like our Walton School has data sets from some major vendors and we offer that out to other schools who do classes on that. We have a lot of others connecting in and using resources at the university. So, it’s a rather complex environment and having Cirrus in there helping and advising us is a huge benefit for us. I understand trying not to dilute the identity stack, but we view Cirrus as a partner along with Microsoft, so we have both of them helping us to get where we need to get.
Response from Geneseo: The benefit is to not have to run CAS or SimpleSAMLphp anymore. CAS was very hard for me to update. I’m not a Java programmer and I frequently had to dig into that Java code every time there was a major update to understand what changed and why my last configuration doesn’t work in the new version. So for me, the benefit was to not have to run those two apps anymore and get a robust, cloud hosted version of those things. One thing I want to be extra-specific about here is the DNS Add-on: this is not an actual extension to our DNS infrastructure, but Cirrus’ branding for essentially them taking over the DNS record for our CAS and SimpleSAML PHP (SSP) service name, and setting up their URL handling to match our own, such that existing CAS and SAML services continue to work without any changes. Where we used to have a DNS A record for our combined CAS and SSP service we now have a CNAME to Cirrus. I apologize if that was already clear, but I wanted to highlight that in case anyone was unsure what “DNS Add-on” actually meant.