SAML IDP-initiated without webtop

so my working irule looks like this:

when ACCESS_POLICY_COMPLETED {
if { [ACCESS::session data get session.server.landinguri] starts_with "/saml/idp/profile/redirectorpost/sso" } { 
    log local0. "SP initiated SAML detected, not sending redirect"
} 
if { [ACCESS::session data get session.server.landinguri] starts_with "/SAMLURL" } {
    log local0. [ACCESS::session data get session.assigned.resources.saml]
    ACCESS::respond 302 Location "https://sso.example.com/saml/idp/res?id=/Common/SAML_Resource"
    log local0. "IDP initiated SAML detected, sending redirect"
} else {
    log local0. "Nothing Matched land on portal"
}}

looks like yours handle the 302 redirect but not the SP-initiated.  do i need to add those lines to both httprequest and accesspolicy completed sections?

now if i could just setup single sign on to my SP initiated SAML application i could add that link to the portal also.

thanks i modified the irule a bit but so far this is working for me: when ACCESS_POLICY_COMPLETED { if { [ACCESS::session data get session.server.landinguri] starts_with "/saml/idp/profile/redirectorpost/sso" } { log local0. "SP initiated SAML detected, not sending redirect" } if { [ACCESS::session data get session.server.landinguri] starts_with "/URLtoIDPinitiated" } { log local0. [ACCESS::session data get session.assigned.resources.saml] ACCESS::respond 302 Location "https://sso.example.com/saml/idp/res?id=/Common/SAML_Resource" log local0. "IDP initiated SAML detected, sending redirect" } else { log local0. "Nothing Matched land on portal" } }

https://devcentral.f5.com/questions/apm-saml-whats-the-best-way-to-have-multiple-idps-using-one-vipanswer123523

;)

You're almost there. Here is what you need to do in terms of iRUles. The gist is that you need to name your IDP resource and redirect to the proper webtop resource. You can try to automate it like you did to dynamically populate respond string, or you can define them statically in the switch statement - that way you can have more user-friendly setup, I believe. Keep in mind that in this case we assume you use Common partition(thus /Common/IDPresourceName reference - substitute that for what your resource is really defined as)

when HTTP_REQUEST priority 30  {
 if {[ACCESS::policy result] eq "allow"; }
 {
      switch -glob [HTTP::path] {
      "/IDPResource";
           {
                HTTP::respond 302 Location "/saml/idp/res?id=/Common/IDPResourceName"
                return
           }
      }
 }

}

` ACCESS Policy Response used to provide IdP Initiated SAML for users that have not logged in yet

when ACCESS_POLICY_COMPLETED priority 30 {
     switch -glob [ACCESS::session data get session.server.landinguri] {
          "/IDPResource"
               {
                    ACCESS::respond 302 Location "/saml/idp/res?id=/Common/IDPResourceName"
                    return
               }
     }
}

same hostname based on the f5 guide for setting up SP and IDP SAML. but the entity for each is differnt resulting in different URL. for example: https://sso.example.com/SPinitiated https://sso.example.com/IDPinitiated

so in my case i would either have to identify them by the URL or go back and define seperate hostnames it sounds like. i have seen several posts on this and most use an irule to send it one way or the other but someting like below did not work for me either. im starting to wonder if the URL i am using to access the IDP-initiated service is wrong. shouldnt https://sso.example.com/IDPinitiated be able to get me to the IDP resource?

when ACCESS_POLICY_COMPLETED { if { [ACCESS::session data get session.server.landinguri] == "/saml/idp/profile/redirectorpost/sso" } { log local0. "SP initiated SAML detected, not sending redirect" } else { ACCESS::respond 302 Location "/saml/idp/res?id=[ACCESS::session data get session.assigned.resources.saml]" log local0. "IDP initiated SAML detected, sending redirect" } }

Are you at least using different host names? You could possibly move the visual policy flow through different paths - one for SP-init

start -> [hostname evaluate] -> SAML auth -> allow

and another for IdP-init

start -> [hostname evaluate] -> [auth] -> advanced resource assign

But generally speaking, you may only need the one IdP VIP and combining all of the SPs into one VIP would be trivial.

well both are sending saml assertions. so its not just single sign on. i just have 1 that is SP-initiated and the other i have to initiate (IDP-initiated) i just cannot afford to hand out public IP addreses for each as im sure there will be more later.

I was definitely not listening when you said "IdP-initiated without the webtop", so I addressed that in your other post. Otherwise, yes I would typically separate IdP and SP functions into separate VIPs. If you think about it, SAML is a federation protocol. If you need SSO to different applications on the same VIP, you can do that without SAML.

If you use a single VIP, then you do indeed need to use a resource assignment.