AD FS 3.0 issue with iPads/iPhone (RelayState, cookie, MSIS7046) RRS feed

  • Question

  • Hello,

    In a development environment at the moment. Setup an (browser) application called SAP Fiori and configured SAML authentication. From a desktop OS 8/10, the configuration is active and functional.  IE (11), Firefox and opera will use (internal) integrated authentication or (external)form authentication and logon.

    Everything works correct!

    On iPad/Iphone (9.2), however...

    When I first go to the https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx, I can logon to the sts and select the site! And it works.

    But when I go first to the url fiori.domain.com, I am correctly redirected to the https://sts.domain.com/adfs/ls.
    the logon page is shown and when enter the credentials, the ADFS3 form throws the below error.

    Encountered error during federation passive request.
    Additional Data
    Protocol Name:
    Relying Party:
    Exception details:
    Microsoft.IdentityServer.Web.CookieManagers.InvalidSamlContextException: MSIS7046: The SAML protocol parameter 'RelayState' was not found or not valid. If the context was stored in cookies, the cookies that were presented by the client were not valid. Ensure that the client browser is configured to accept cookies from this website and retry this request.
       at Microsoft.IdentityServer.Web.CookieManagers.EncodedContext.InitializeSamlProtocolContext(Uri baseUrl, String encodedValue)
       at Microsoft.IdentityServer.Web.CookieManagers.EncodedContext..ctor(String encodedValue, Boolean samlEnabled, Boolean wsFederationEnabled)
       at Microsoft.IdentityServer.Web.CookieManagers.RequestCookieManager.Load(Boolean samlEnabled, Boolean wsFederationEnabled, WrappedHttpListenerRequest context)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
       at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    The iPad has "allow all cookies" enabled. I have tested with Safari, Firefox, chrome and Opera, same result..

    I have seen this tread also, but they gave up... https://social.technet.microsoft.com/Forums/windowsserver/en-US/5e8be1ac-e8da-47e5-b1d7-f708b51536cb/ad-fs-3-adfs3-issue-with-ipads?forum=winserverDS

    Environment setup:

    F5-> WAP (2012r2)   <-> AD FS (2012r2)
           <-> SAP Fiori (App)
           <-> Topdesk (App)
           <-> ...




    When I go the url:

    https://fiori.domain.com I get the above error (You can see that your are redirected to sts). When you enter the same url (https://fiori.domain.com) again in the browser, You are in! So the authentication is OK, but AD FS displays an error in the logon page...

    Thursday, December 31, 2015 8:02 AM


All replies

  • Hey Erning,

    I've seen this problem occur due to the same reason mentioned in the forum post you linked. The Safari browser does not allow cookies over 4096 bytes. ADFS makes use of cookies to maintain your authentication state. If you are passing through a lot of claim data into your cookies, then those cookies are very likely to fail authentication.

    Often, this occurs when you are passing through all group membership information or certificate information.

    Look at your Relying Party claim rules - Issuance Transform Rules. Try to reduce the information you pass through to the token. If you need specific groups to be passed, pass only those groups and not others.

    Good Luck!


    Thursday, December 31, 2015 7:40 PM
  • Any update on this?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, January 13, 2016 4:05 PM
  • We made fiddler trace and followed the packages and we see that iOS is dropping packages. Answer by MS:

    In such scenarios what we can recommend is:

    1. The proper way to address this is to call Apple (Safari/iOS Vendor) and ask them to provide a fix for Safari to prevent the loss of your data. (iOS problem all the browsers are not working)
    2. Call your application vendor and ask them to NOT sign the SAMLRequest they are sending. This would make the SAMLRequest smaller and probably overcome the browser limitation (This is not working all the time). Or


    Regarding the RFC recommendations about cookies these are the latest RFC, RFC 6265, minimal recommendation


    6.  Implementation Considerations


    6.1.  Limits


         Practical user agent implementations have limits on the number and

         size of cookies that they can store.  General-use user agents SHOULD

       provide each of   the following minimum capabilities:


         o  At least 4096 bytes per cookie (as measured by the sum of the

            length of the cookie's name, value, and attributes).


         o  At least 50 cookies per domain.


         o  At least 3000 cookies total.


         Servers SHOULD use as few and as small cookies as possible to avoid

         reaching these implementation limits and to minimize network

         bandwidth due to the Cookie header being included in every request.


         Servers SHOULD gracefully degrade if the user agent fails to return

         one or more cookies in the Cookie header because the user agent might

         evict any cookie at any time on orders from the user.



    ADFS is setting 4/5 cookies.  This is far less them the minimum 50 recommended by RFC 6265 or even the older and more  conservative RFC 2109 that specified 20.

    About the size of the cookies, ADFS sets 2001 bytes per cookie value, which tops to a maximum of 2048 including name, value and attributes.


    RFCs that define Cookies:              



    About the currently supported browsers under ADFS these are documented here, and documentation is subject to change without notice.


    Appendix A: Reviewing AD FS Requirements



    AD FS Requirements - Browser Requirements




    So in this scenario the SAMLRequest token, sent by the relying party, and to be returned to ADFS by the browser cookies is not sent back to ADFS complete.

    This issue with Safari and cookies limitation has been identified by other users on the Apple forums.


    In this scenario, AD FS is performing exactly as it should, your application is sending a SAMLRequest as it should, but the client browser is dropping your important data.


    The two above solutions are not applicable, call Apple and not sign the SAMLRequest.... We have a workarround to redirect the people to AD FS landingpage /adfs/ls/idpinitiatedsignon.aspx

    The above problem setting is when you use SP Post, all the trafic is send to the client. When you use Artifact, the communication is between the IP and the SP so you don't have the cookie problem :).


    Friday, January 22, 2016 10:12 PM
  • So you're good? Are you using Artifact in your case then?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, January 25, 2016 6:56 PM
  • Hello Pierre,

    I don't know yet, because we have some configuration problems with the F5.

    But can you confirm that the solution is to use Artifact instead of POST, to solve the issue?

    Wednesday, February 17, 2016 9:11 PM
  • As a side note:

    "About the size of the cookies, ADFS sets 2001 bytes per cookie value, which tops to a maximum of 2048 including name, value and attributes."

    What does this mean? That each cookie is only 2048 bytes?

    How does this tie in with the iOS limit?

    Wednesday, February 17, 2016 9:38 PM
  • Hi, the SSO cookie size is usually the cause of this and this is typically because group memberships were stored in the SSO cookie for ADFS versions prior to ADFS 2012R2.

    If you are seeing this on ADFS 2012R2, please work with MSFT support on this.

    If you are seeing this on ADFS 2.0, ADFS 2012, then remove the group SID as pass through in the AD CP trust and wherever you are using groups in issuance authorization rules or issuance claims rules for the app, use 'tokengroups' attribute in AD to get the groups and then drive the rule.


    //Sam (@MrADFS)

    Thursday, February 25, 2016 10:57 PM
  • @Sam - could you please clarify this?

    In 2012 R2 where are group memberships now stored?

    The claims rules are :

    • Token-Groups (TG) as SIDs
    • TG - Qualified by DN
    • TG - Qualified by Long DN
    • TG - Unqualified Names

    Are you saying remove "Token-Groups (TG) as SIDs" and use one of the others?

    Curious as to the rationale for this?

    Friday, February 26, 2016 12:44 AM
  • @Sam:

    Would going for ADFS 2012R2 be an option to resolve the issue?



    Tuesday, December 6, 2016 9:12 AM
  • The problem still remains with ADFS 3.0 (Windows Server 2012R2).

    Just like Perry said...

    This is caused by a "total cookie size limit per domain" in Safari on iPhone/iPad.

    I wish Apple would realize that they need to fix this and finally solve it as this has been a problem for several years now and it's not just Safari on iPhone/iPad... it's any browser on iPhone/iPad since they all use the same IOS sub-components and aren't much more than "skins" that provide a different GUI and some other features.

    What happens is that Safari doesn't send all cookies back to ADFS, typically only 2 out of 4 cookies are sent back which results in an incomplete SAML Request and no RelayState data at all (RelayState data is appended to the end of the SAML Request) so ADFS has no idea what the request wants (that's why you don't see any information in the error about which Relying Party that was requested).

    We encountered this when a NetScaler was reconfigured to use a certificate for the RST that was signed with a SHA-256 algorithm. Previously we were using a certificate signed with a SHA-1 algorithm and the RST was slightly smaller... just enough to fit in 3x 2KB cookies and one 300 byte cookie. The only claim/assertion in the SAML Token was NameID. Using a slightly larger SHA-256 certificate broke the camels back. The fourth cookie became 1.2KB which caused Safari on iPhone/iPad to only send the first two cookies back to ADFS.

    There are a few workarounds:

    1. If you can, don't sign the RST from NetScaler - This will make the SAML Token form NetScaler MUCH smaller and you might be able to fit the SAML Request in 3x cookies which are 2KB and and forth that isn't too big.

    2. If you can, use a self-signed certificate for the RST from NetScaler without any parent certificate (not chained to any intermediate or root) and/or enter as little data when creating the certificate. A smaller certificate might do the trick for you.

    3. Only issue claims/assertions that you really need.

    Wednesday, December 14, 2016 9:54 PM
  • Good news !!!

    We've worked with Apple on this issue and it has been fixed in iOS 11.

    Thursday, October 12, 2017 2:14 PM
  • Hi!

    We're facing this issue in a current project and from what I can tell it has not been fixed in iOS 11 (or 11.1 which was just released). It works on the Mac and PC but not in iOS unless you authenticate in a private window (which is super weird but perhaps some less important cookies are being removed from the response which in return let's it pass).

    P.S We're testing on a iOS simulator, which shouldn't be a problem but who knows.
    • Edited by Tomas Green Wednesday, November 1, 2017 11:18 AM
    Wednesday, November 1, 2017 11:16 AM