Similar to #111, ADFS support for authentication might result in weird corner cases. This PR works for the authentication flow on https://webmail.lu.se/owa/ which has a few quirks. The changes should not break existing form authentications.
For documentation reasons, I quickly summarize the key points of the auth flow.
https://webmail.lu.se/owa/ 302 redirects to
https://adfs.lu.se/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fwebmail.lu.se%2fowa%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fowa%252f&wct=2023-02-10T07%3a20%3a38Z
where the wctparameter uses the current time, probably as a nonce.
This page has the usual login form, however the form name is loginForm. The action is the same url with an additional client-request-id attribute in the form of a uuid.
/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fwebmail.lu.se%2fowa%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fowa%252f&wct=2023-02-10T07%3a20%3a38Z&client-request-id=<uuid>
The uuid is fixed, maybe per version.
This form post request replies with a set cookie of name MSISAuth and then redirects to the same url as get. On get it returns a redirect page which is a form of 3 hidden fields:
The context from the initial redirect wctx is rm=0&id=passive&ru=%2fowa%2f
The action wa is wsignin1.0
and
wresult is <t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"><t:Lifetime><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-02-10T07:20:42.574Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-02-10T08:20:42.574Z</wsu:Expires></t:Lifetime><wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">...
The form is automatically submitted via javascript to https://webmail.lu.se:443/owa/. It is important here to include a Referer, which can be any url. To parse the wresult correctly, the parser must allow html like tags (>) inside a form value. To post the data programmatically, I had to replace the html escaped sequences < to < and " to ".
The same applies for wctx where & is replaced by &.
Finally the post returns a list of cookies, namely FedAuth, FedAuth1, TimeWindowKey, TimeWindowIV, TimeWindowSig
which allow interaction with the owa.
Similar to #111, ADFS support for authentication might result in weird corner cases. This PR works for the authentication flow on https://webmail.lu.se/owa/ which has a few quirks. The changes should not break existing form authentications.
For documentation reasons, I quickly summarize the key points of the auth flow.
https://webmail.lu.se/owa/
302 redirects tohttps://adfs.lu.se/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fwebmail.lu.se%2fowa%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fowa%252f&wct=2023-02-10T07%3a20%3a38Z
where thewct
parameter uses the current time, probably as a nonce.This page has the usual login form, however the form name is
loginForm
. The action is the same url with an additionalclient-request-id
attribute in the form of a uuid./adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fwebmail.lu.se%2fowa%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fowa%252f&wct=2023-02-10T07%3a20%3a38Z&client-request-id=<uuid>
The uuid is fixed, maybe per version. This form post request replies with a set cookie of nameMSISAuth
and then redirects to the same url as get. On get it returns a redirect page which is a form of 3 hidden fields: The context from the initial redirectwctx
isrm=0&id=passive&ru=%2fowa%2f
The actionwa
iswsignin1.0
andwresult
is<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"><t:Lifetime><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-02-10T07:20:42.574Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-02-10T08:20:42.574Z</wsu:Expires></t:Lifetime><wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">...
The form is automatically submitted via javascript to
https://webmail.lu.se:443/owa/
. It is important here to include a Referer, which can be any url. To parse thewresult
correctly, the parser must allow html like tags (>) inside a form value. To post the data programmatically, I had to replace the html escaped sequences<
to < and"
to ". The same applies forwctx
where&
is replaced by &.Finally the post returns a list of cookies, namely
FedAuth, FedAuth1, TimeWindowKey, TimeWindowIV, TimeWindowSig
which allow interaction with the owa.