Attending: Rob Carter, Etan Weintraub, Brian Arkills, Marcus

Mizushima, Shilen Patel, Majeed Abu-Quibain, Jeffrey C (UCLA)

Regrets:  Les LaCroix


<Start recording:  14:06>

Etan: Reminder: this is recorded.  It won't be published, but it will

be used to help with notes and such.  I think that's the


Etan:  Notes?

Rob:  I'll help.

Majeed:  I'll help too.

Etan: On that note: From out last meeting, I had a task to generate a

linked IDP scenarios document, and a table we can use to manage that.

Fortunately, Brian started that and saved me the trouble of starting

it.  I made a few modifications, and the result is in the private area

of the working group wiki.

<Etan screen share>

Etan: What we've done is lay thes out with "login IDP" (which is the

IDP that's at the top of the stack -- where the user actually logs

in), then "linked IDPs" (which could be more than one), method of

link, issues, significant benefits, and then if you need to break out

more details and who the responsible party is for the scenario.

There's a way to sort these things, so...  I'm taking the Azure

(login) -> Shib (linked) scenario.  I'm taking that one.  You can @

yourself in the "WG Responsible Party" field to take one.

Etan: We have different models depicted -- Shib->Azure AD, Azure AD ->

Shib, Azure AD -> Cirrus, etc...  The ones you can see there are the

ones we have right now.  I'll try to go in over the next two weeks and

put in more info on the one I've claimed -- stuff about benefits,

issues, etc.

Etan: Now that I'm talking through it, I wonder if we should put in a

field for "reasons" for going this way -- it might fit under

"benefits" as well -- but some reference to why an org might want to

use this scenario.

Etan:  Does anyone else want to claim one while we're here?

Jeffrey: Our institution is looking into Okta, so I'm wondering if

anyone from a school with Okta would be interested in getting one of

those scenarios into the mix?

Etan: I don't recall anyone mentioning Okta as something they're using

in the member survey...  We looked at Okta a while back, but decided

Azure was just as good for our purposes and cheaper., but we can look

and see if anyone has Okta experience or is actively using it and see

if we can get that into the mix.  Are the other of the listed

scenarios people want to take?

Majeed: I'll definitely take the OAM->CAS one.  Is that too

special-case for our environment to be useful for our purposes,

though?  Maybe from the perspective of a migration example -- it could

be a linkage for migration purposes.

Etan: I think it's useful to share the information.  Maybe at some

point we separate things out so we have recommended solutions and

other solutions we've got information about, and this might not be a

recommended solution.

Majeed: Yeah -- this is something we wouldn't want to do forever --

for the long term, we wouldn't recommend it, but it's a way out of a

legacy system.  I might also think we might want to have something

about linking into Azure AD in order to use Azure MFA (possibly with

Shibboleth).  We combine Shib with Azure AD to use Azure MFA with Shib

for the login page.  (AAD->ADFS->Shib w/ Shib login and Azure MFA for

shib protected apps)

Brian: That's a unique scenario we should probably have a different

row for.

Majeed:  I can take the AAD->ADFS->Shib(MFA) one.

Shilen:  If...

Etan:  Any others?  I can't take Cirrus...

Jeffrey: There is a use case we have but I don't recommend that has to

do with using some custom Unicon code to link Shib to Okta because our

medical enterprise uses Okta...  But if folks want it documented, I

can get it in there.

Etan: It may be worth getting that in there just for purposes of

noting that it's *not* recommended, because some folks may think of it

as something they *could* do, and be interested to know that we don't

recommend it (explicitly).

Jeffrey: Not sure how to put it down, since it's a sorta strange

dependency -- sometimes users us shib, sometimes they use Okta -- but

I can take it if we can figure out how to describe it.

Brian: I put into chat that there are quite a few univs using Cirrus

-- you can put me down in Cirrus, since we explored it pretty deeply,

without actually getting the product.  It'd be great if we could get

one of teh R1s actually using Cirrus that I put in chat (IAState,

Yale, Berkley, Mich, MIT, CMU, Indiana, Arizona, Oregon) to report for

us on it.

Jeffrey: And we want folks who actually have things deployed, right?

Not just have Cirrus report on it for themselves?

Brian: You can put me down next to the other Shib/Azure Ad environment

-- we were in that configuration for 9-10 years before -- I have a lot

of experience with it, but we're not using it anymore.

Etan: We were in that mode too, but I didn't like it and I didn't want

to take it because of that.  We had SiteMinder in front of Shib, then

ADFS, then AAD -- it got to be a nightmare.

Jeffrey: I am curious about the specific reasons (apart from

complexity) that drive you to unfederate Microsoft stuff.  Not for

this conversation -- just thanks for offering to take that topic,

since it would be nice to understand why you chose to unfederate.

Brian: I had originally put in a row that was essentially an unlinked

scenario, but I removed it because it's not really topical for us.

Etan: Right -- we should probably have scenarios where we're actually

doing linking.

Jeffrey: But it's about the experience, right?  We do have linked

scenarios on the list, but where someone's decided to unfederate and

undo a linkage altogether, the reasons for that linking are probably

worth exposing.

Etan:  Well, we just got rid of ADFS.

Jeffrey: Yeah -- I think Brian's situation was more that they chose to

unfederate the application environment, and why that happened would be

interesting to discuss, for folks thinking about making that decision

-- looking to federate for the user experience use case, but if there

are reasons they might want to consider that doing that would be

undesirable, it'd be useful to know that.

Etan: From our perspective, we want to have one user login -- any time

we have more than one, we find that users are much more easily

phished.  Phishing is a major problem, and we've gone to a very strict

"everything must use our websso" model, and if you have a problem with

that, you need to talk to the CISO.  We're staying federated in Azure

because of that.  As far as why we made AAD the front end and then

shib, it was mostly because we got a directive to use AAD MFA rather

than our own home grown one, and it made more sense to use Azure for

everything if we needed to do that than to do all the back-and-forth

that would be required otherwise.

Jeffrey: That makes sense.  I didn't mean to derail us, but...

Brian...  Your use case for *un*federating...  You have both a Shib

login page and an AAD login page and that's not a problem for you?

Brian: And prior to that, we had uses going to AAD, putting in their

UPN, then get redirected to Shib where they enter their userid a

different way, then they come back to the MS experience and they get

the "you're signed in" dialog from Microsoft...  So to say that we had

a single SSO experience was kinda false in that configuration.  It's a

convenient bending of the language to say that, but the experience was

actually not that.  I think Etan's configuration is a bit more SSO in

terms fo the experience, but it's the reverse direction, so that

experience is different.

Brian: The token lifetime issue we ran into was a major issue, and our

primary ADFS support person left, so we were having trouble supporting

that.  And we were starting to see some edge cases where federation at

Microsoft wasn't working quite properly.  On the Microsoft end, they

like you to be in a "managed" rather than "federated" configuration --

password hash synchronization or passthru authentication to a local

AD.  Their experiences for apps inside Microsoft are a bit better than

if you're federated...  SQL Server folks at Microsoft were promoting

some odd scenarios where Microsoft could have SQL servers be able to

authenticate as arbitrary users in your tenant with federation, and

claiming it as an advantage of federating, but we saw it as... not an


Majeed: From our perspective, a lot of it has to do with simplifying

how many different environments we have to manage and have to teach

our users to navigate.  We do things with HRD replacement that get

around some of the experiential stuff (people getting asked for their

email address to find the right IDP to access from the Microsoft

federation endpoint).  That only works in specific cases that we care

about, but it works for what we care about.

Brian: I didn't cover our MFA scenario -- we had to do a bunch of

customization to get MFA to work properly (with only one MFA prompt

for users accessing Azure AD apps) when we got MFA started.  We

preferred because of that to go with unfederated.  I imagine over time

we may gravitate toward something like Etan's solution, but because of

the individuals involved here at the time, that wasn't going to

happen.  I think the folks on the ground here are probably supportive

of moving in that direction, though -- it's just a matter of when

we're ready to make a decision.

Majeed:  Thanks -- sorry for derailing.

Etan: No derailing at all -- I think this is stuff we should discuss.

In our environment we have things that are directly using Azure AD and

not going through Shib, but we try to get everything to go through the

full stack.  We have failover in the event of a network outage on the

outside that gets around the linkage.

Jeffrey: Can you tell us more about how you do that split between

using AAD directly or using AAD + Shib?

Etan: We took our old on-prem login page and built it into an apache

forms environment.  We Have a backup IDP running in a separate Tomcat

that has a different configuration and doesn't depend on AAD.  Once

upon a time we had it set up as separate servers, but we moved to

newer servers with multiple tomcat instances.  we have a script that

flips a deployed system from one plan to the other.  It changes the

reverse proxy configuration in the Apache configuration and restarts

Apache on each box to effect the flip.

Majeed: When you switch to the failover, you're using MPS for MFA


Etan: In failover, if Azure is up, we do MPS, but if not, our on-prem

MFA (RADIUS-based) will work, but only for those of us who have that

available.  We use that for our text messaging MFA and a few other

things, so we recommend that users get enrolled in the backup MFA

system...  We haven't quite gotten to the point of being able to take

the Microsoft phone number and put it into the text system

automatically to do text-based MFA...  Has to do with carrier

information being hard to come by for telephone numbers in Azure...

Etan: So, I'm gonna try to take Brian's advice from earlier and say if

there are no other conversations we need to take now, we can adjourn

early.  I'll send something to the list about this linked IDP

scenarios page, and get folks to come in and volunteer ones that

aren't taken already.

Shilen: We can add a row if you want for our IDP extension for doing

WS-Fed/WS-Trust to get around some of the issues with linking to


Brian: We can add a row for that -- I think it's worth adding a row

for that, too.

Brian: I aslo shared a link in chat to an analysis we did a few years

ago when we started thinking about doing MFA with Azure AD -- it has a

structure similar to our rows with info about where 2-factor

enforcement point would be.

  • No labels