Displaying the username requested by Microsoft

Max Nuding max.nuding at uni-konstanz.de
Tue Mar 24 13:04:46 UTC 2026


 > Fundamentally, no, it's not how SAML works, and it's not the right 
way to do this (defining a message extension is).

I'd much rather do something more in line with how SAML works.
The problem we are facing is the following: Some users have multiple 
accounts configured in Outlook. They sometimes need to re-authenticate, 
so Outlook opens our IdP login window in-app. But because they have 
multiple accoutns configured, they don't know which credentials to 
enter. The only hint Outlook is giving us is a non-standard additional 
form value in the POST request. I'd prefer something more sensible, but 
I cannot control that end. So I'm stuck with what I have.

Do you happen to have any overview on how to do a custom inbound 
interceptor flow? 
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199511979/ProfileHandling#Authoring-and-Enabling-Intercepts 
is not very useful.

Best
Max



On 24/03/2026 13:10, Scott Cantor via users wrote:
> 
> 
>> On Mar 24, 2026, at 7:57 AM, Peter Schober via users <users at shibboleth.net> wrote:
>>
>> Max Nuding via users <users at shibboleth.net> [2026-03-24 12:17 CET]:
>>> For users coming from Microsoft the POST to /idp/profile/SAML2/POST/SSO
>>> includes (in addition to the SAMLRequest and RelayState parameters) a
>>> "username" parameter. This contains the username which had been entered into
>>> the username form from Microsoft.
>>
>> Not that this helps you in any way but... isn't that illegal in SAML?
> 
> It isn't explicitly precluded, but it's not the intention.
> 
> It has to be grabbed during intial contact with an inbound interceptor flow and stashed off in the flow conversation, or ScratchContext. Details of that are beyond the scope of me answering occasional questions here.
> 
> Fundamentally, no, it's not how SAML works, and it's not the right way to do this (defining a message extension is).
> 
> -- Scott
> 

-- 
Herr Max Nuding
Sachgebiet Identity und Access Management, Sachgebiet Softwareentwicklung
Abt. IT-Dienste für Forschung, Lehre und Infrastruktur
Kommunikations-, Informations-, Medienzentrum (KIM)
Universität Konstanz
78467 Konstanz
Tel: +49.7531.88-4658
Raum: B707

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5056 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20260324/0be39be6/attachment.p7s>


More information about the users mailing list