SAML, Office365 and UserName

I was recently setting up Office 365 w/ SAML federation and one of the things you lose when doing SAML (as oppose to WS-Trust/WS-Fed) is the auto-populating of the user's login ID on the NAM login page. So when a user goes to say outlook.office.com, enters their login/UPN, and then gets redirected to the IdP, they have to enter their login ID a second time. That was always one of the tradeoffs of dong SAML vs. WS-FED/WS-TRUST.

So I was just recently watching the SAML process using SAML tracer and I noticed in the POST from Microsoft, besides the SAMLRequest and the RelayState, they also include the username in that POST to /saml2/sso.

My question is, is there any safe way to consume the username and pre-populate the login box like you can for WS-FED/WS-Trust? Even if it is possible to grab, does this raise security concerns (e.g. XSS attacks) since it is outside the SAML spec (I assume it's outside the spec, maybe it is not?).

Thanks.

Matt
  • On 22-03-2019 10:14 AM, matt wrote:
    >
    > I was recently setting up Office 365 w/ SAML federation and one of the
    > things you lose when doing SAML (as oppose to WS-Trust/WS-Fed) is the
    > auto-populating of the user's login ID on the NAM login page. So when a
    > user goes to say outlook.office.com, enters their login/UPN, and then
    > gets redirected to the IdP, they have to enter their login ID a second
    > time. That was always one of the tradeoffs of dong SAML vs.
    > WS-FED/WS-TRUST.
    >
    > So I was just recently watching the SAML process using SAML tracer and I
    > noticed in the POST from Microsoft, besides the SAMLRequest and the
    > RelayState, they also include the username in that POST to /saml2/sso.
    >
    >
    > My question is, is there any safe way to consume the username and
    > pre-populate the login box like you can for WS-FED/WS-Trust? Even if it
    > is possible to grab, does this raise security concerns (e.g. XSS
    > attacks) since it is outside the SAML spec (I assume it's outside the
    > spec, maybe it is not?).


    Are you sure you captured the auth request and not the auth response? Its been a while since I've done this but this is a auth request from o365 i
    have in my notes:

    <samlp:AuthnRequest ID="_df308266-2171-416f-acd9-80e938105c49" Version="2.0"
    IssueInstant="2018-02-23T10:46:41.290Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
    </samlp:AuthnRequest>


    there's no username in there


    --
    Cheers,
    Edward
  • edmaa;2497277 wrote:
    On 22-03-2019 10:14 AM, matt wrote:
    >
    > I was recently setting up Office 365 w/ SAML federation and one of the
    > things you lose when doing SAML (as oppose to WS-Trust/WS-Fed) is the
    > auto-populating of the user's login ID on the NAM login page. So when a
    > user goes to say outlook.office.com, enters their login/UPN, and then
    > gets redirected to the IdP, they have to enter their login ID a second
    > time. That was always one of the tradeoffs of dong SAML vs.
    > WS-FED/WS-TRUST.
    >
    > So I was just recently watching the SAML process using SAML tracer and I
    > noticed in the POST from Microsoft, besides the SAMLRequest and the
    > RelayState, they also include the username in that POST to /saml2/sso.
    >
    >
    > My question is, is there any safe way to consume the username and
    > pre-populate the login box like you can for WS-FED/WS-Trust? Even if it
    > is possible to grab, does this raise security concerns (e.g. XSS
    > attacks) since it is outside the SAML spec (I assume it's outside the
    > spec, maybe it is not?).


    Are you sure you captured the auth request and not the auth response? Its been a while since I've done this but this is a auth request from o365 i
    have in my notes:


    <samlp:AuthnRequest ID="_df308266-2171-416f-acd9-80e938105c49" Version="2.0"
    IssueInstant="2018-02-23T10:46:41.290Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
    </samlp:AuthnRequest>


    there's no username in there


    --
    Cheers,
    Edward


    It's not in the the SAMLRequest itself, it's in the POST to the IdP. It's a separate variable being posted to /nidp/saml2/sso. Hence my concern, it's technically not part of the SAML spec at all (at least I don't think it is). Microsoft is just adding it to the POST as another variable. Take a trace with something like Fiddler and you'll see it.

    What made me start looking was I know NetIQ competitors are able to get the username and I couldn't figure out how they were doing it precisely because it is not part of the spec AFAIK. So I took a trace and now I can see it. In the POST you see SAMLRequest= which is the standard AuthN request (like in your reply above) AND you see username= with the user's UPN/login ID.

    So then I started thinking, can we do that too? Can we consume that username field somehow and avoid having the user enter their login ID a second time when doing SAML with O365.

    I don't think just a custom login page will do it, I think there would need to be some programmatic change in the IdP to consume it. But I'm not sure. I'm also not sure if there are XSS ramifications to consuming it as well.

    But it would be nice if we could do what all the other vendors are doing.

    Matt
  • On 24-03-2019 2:34 AM, matt wrote:
    >
    > edmaa;2497277 Wrote:
    >> On 22-03-2019 10:14 AM, matt wrote:
    >>>
    >>> I was recently setting up Office 365 w/ SAML federation and one of

    >> the
    >>> things you lose when doing SAML (as oppose to WS-Trust/WS-Fed) is the
    >>> auto-populating of the user's login ID on the NAM login page. So when

    >> a
    >>> user goes to say outlook.office.com, enters their login/UPN, and then
    >>> gets redirected to the IdP, they have to enter their login ID a

    >> second
    >>> time. That was always one of the tradeoffs of dong SAML vs.
    >>> WS-FED/WS-TRUST.
    >>>
    >>> So I was just recently watching the SAML process using SAML tracer and

    >> I
    >>> noticed in the POST from Microsoft, besides the SAMLRequest and the
    >>> RelayState, they also include the username in that POST to

    >> /saml2/sso.
    >>>
    >>>
    >>> My question is, is there any safe way to consume the username and
    >>> pre-populate the login box like you can for WS-FED/WS-Trust? Even if

    >> it
    >>> is possible to grab, does this raise security concerns (e.g. XSS
    >>> attacks) since it is outside the SAML spec (I assume it's outside the
    >>> spec, maybe it is not?).

    >>
    >> Are you sure you captured the auth request and not the auth response?
    >> Its been a while since I've done this but this is a auth request from
    >> o365 i
    >> have in my notes:
    >>
    >>>

    > Code:
    > --------------------
    > > >

    > > <samlp:AuthnRequest ID="_df308266-2171-416f-acd9-80e938105c49" Version="2.0"
    > > IssueInstant="2018-02-23T10:46:41.290Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    > > <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer>
    > > <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
    > > </samlp:AuthnRequest>
    > >

    > --------------------
    >>>

    >>
    >> there's no username in there
    >>
    >>
    >> --
    >> Cheers,
    >> Edward

    >
    > It's not in the the SAMLRequest itself, it's in the POST to the IdP.
    > It's a separate variable being posted to /nidp/saml2/sso. Hence my
    > concern, it's technically not part of the SAML spec at all (at least I
    > don't think it is). Microsoft is just adding it to the POST as another
    > variable. Take a trace with something like Fiddler and you'll see it.
    >
    > What made me start looking was I know NetIQ competitors are able to get
    > the username and I couldn't figure out how they were doing it precisely
    > because it is not part of the spec AFAIK. So I took a trace and now I
    > can see it. In the POST you see SAMLRequest= which is the standard
    > AuthN request (like in your reply above) AND you see username= with the
    > user's UPN/login ID.
    >
    > So then I started thinking, can we do that too? Can we consume that
    > username field somehow and avoid having the user enter their login ID a
    > second time when doing SAML with O365.
    >
    > I don't think just a custom login page will do it, I think there would
    > need to be some programmatic change in the IdP to consume it. But I'm
    > not sure. I'm also not sure if there are XSS ramifications to consuming
    > it as well.
    >
    > But it would be nice if we could do what all the other vendors are
    > doing.


    ah ok, i see what you mean now. Unfortunately i don't have a O365 lab to play with. It would indeed be nice to allow for this if you use email address
    as the userID. Unfortunately this forum isn't monitored by product management so the best way to raise this would be through:
    https://www.microfocus.com/products/enhancement-request/




    --
    Cheers,
    Edward
  • Hi Matt,

    It may be possible to grab the parameter in the login JSP but not sure.
    I will look into this, we have several customers with O365 SSO set up.

    /Mark


    On 2019-03-23 15:34:01 0000, matt said:

    > edmaa;2497277 Wrote:
    >> On 22-03-2019 10:14 AM, matt wrote:
    >>>
    >>> I was recently setting up Office 365 w/ SAML federation and one of

    >> the
    >>> things you lose when doing SAML (as oppose to WS-Trust/WS-Fed) is the
    >>> auto-populating of the user's login ID on the NAM login page. So when

    >> a
    >>> user goes to say outlook.office.com, enters their login/UPN, and then
    >>> gets redirected to the IdP, they have to enter their login ID a

    >> second
    >>> time. That was always one of the tradeoffs of dong SAML vs.
    >>> WS-FED/WS-TRUST.
    >>>
    >>> So I was just recently watching the SAML process using SAML tracer and

    >> I
    >>> noticed in the POST from Microsoft, besides the SAMLRequest and the
    >>> RelayState, they also include the username in that POST to

    >> /saml2/sso.
    >>>
    >>>
    >>> My question is, is there any safe way to consume the username and
    >>> pre-populate the login box like you can for WS-FED/WS-Trust? Even if

    >> it
    >>> is possible to grab, does this raise security concerns (e.g. XSS
    >>> attacks) since it is outside the SAML spec (I assume it's outside the
    >>> spec, maybe it is not?).

    >>
    >> Are you sure you captured the auth request and not the auth response?
    >> Its been a while since I've done this but this is a auth request from
    >> o365 i
    >> have in my notes:
    >>
    >>>

    > Code:
    > --------------------
    > > >

    > > <samlp:AuthnRequest ID="_df308266-2171-416f-acd9-80e938105c49"

    > Version="2.0"
    > > IssueInstant="2018-02-23T10:46:41.290Z"

    > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    > > <Issuer

    > xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer>
    >
    > > <samlp:NameIDPolicy

    > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
    > > </samlp:AuthnRequest>
    > >

    > --------------------
    >>>

    >>
    >> there's no username in there
    >>
    >>
    >> --
    >> Cheers,
    >> Edward

    >
    > It's not in the the SAMLRequest itself, it's in the POST to the IdP.
    > It's a separate variable being posted to /nidp/saml2/sso. Hence my
    > concern, it's technically not part of the SAML spec at all (at least I
    > don't think it is). Microsoft is just adding it to the POST as another
    > variable. Take a trace with something like Fiddler and you'll see it.
    >
    > What made me start looking was I know NetIQ competitors are able to get
    > the username and I couldn't figure out how they were doing it precisely
    > because it is not part of the spec AFAIK. So I took a trace and now I
    > can see it. In the POST you see SAMLRequest= which is the standard
    > AuthN request (like in your reply above) AND you see username= with the
    > user's UPN/login ID.
    >
    > So then I started thinking, can we do that too? Can we consume that
    > username field somehow and avoid having the user enter their login ID a
    > second time when doing SAML with O365.
    >
    > I don't think just a custom login page will do it, I think there would
    > need to be some programmatic change in the IdP to consume it. But I'm
    > not sure. I'm also not sure if there are XSS ramifications to consuming
    > it as well.
    >
    > But it would be nice if we could do what all the other vendors are
    > doing.
    >
    > Matt



  • On 27-03-2019 6:57 PM, mvreijn wrote:
    > Hi Matt,
    >
    > It may be possible to grab the parameter in the login JSP but not sure.
    > I will look into this, we have several customers with O365 SSO set up.


    That posted data will be long gone by the time the login page gets called. To do this the SAML code would have to store it somewhere and given that it
    is outside the SAML spec NAM wouldn't be expecting it.


    --
    Cheers,
    Edward