Sharing User Credentials Between SAML IDP and SP Policies in F5 APM
In F5 APM environments with one SAML Identity Provider (IDP) and multiple Service Providers (SPs), SP policies may need access to user credentials (like passwords) for SSO mechanisms such as NTLM or RDP. Since SAML doesn't transmit passwords, this solution enables secure credential sharing by storing the password in a custom session variable on the IDP side and passing the IDP session ID to the SP as a SAML attribute. An iRule on the SP side then uses this session ID to retrieve the password from the IDP session, making it available for SSO credential mapping. This approach maintains security by avoiding password exposure in the SAML assertion and leverages internal session sharing between policies.
SaaS Federation iApp
Problem this snippet solves: f5.saas_idp.v.1.0.1rc1 The official release candidate iApp template has been posted to downloads.f5.com in the RELEASE_CANDIDATE directory of the iApp package. This release has the following changes: Added support for BIG-IP v12.1 Modified the 'SP Initiated?' field in the iApp to 'IdP Initiated?' and the values to 'No, SP only' and 'Yes, IdP and SP' to make this section more clear. f5.saas_idp.v.1.0.0rc1 This release candidate version of the iApp template, released on 4/20/16, provides improved functionality and additional options. The deployment guide has also been substantially updated. f5.saas_idp.v.0.9.0 This iApp allows you to configure F5 BIG-IP Access Policy Manager(APM) as SAML Identity Provider(IdP) to 11 commonly used SaaS applications: Office 365 Salesforce.com Workday Amazon Web Services(limited support) Concur Service-Now Jive Wombat Zendesk WebEx Google Apps How to use this snippet: For information on how to download, install, and use the iApp (and various other prerequisites), see the deployment guide for this configuration: http://f5.com/pdf/deployment-guides/saml-idp-saas-dg.pdf Code : https://downloads.f5.com/esd/product.jsp?sw=BIG-IP&pro=iApp_Templates
APM SAML IdP - SP Issuer Extraction
Problem this snippet solves: APM doesn't expose any detail about the SAML SP Issuer when authentication requests hitting APM as an IdP during an SP initiated SAMLRequest. This iRule when applied to a SAML IdP enabled virtual server will extract the assertion request, decode it and present the SAML SP Issuer ID as the session variable %{session.saml.request.issuer} within APM. How to use this snippet: This comes in real handy when performing authorisation of the resource and could help avoid having APM perform a TCP connection reset when a SAML resource isn't authorised. Code : when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { if { [HTTP::path] equals "/saml/idp/profile/redirectorpost/sso" } { if { [HTTP::method] equals "POST" } { # Colelct POST data set content_length [HTTP::header value Content-Length] HTTP::collect $content_length } elseif { [HTTP::method] equals "GET" } { #TODO } } } when HTTP_REQUEST_DATA { set payload_data [URI::decode [HTTP::payload]] log local0. "payload=[URI::query "?$payload_data" "SAMLRequest"]" if { $payload_data contains "SAMLRequest" } { # Extract SAML request data set SAMLdata [b64decode [URI::query "?$payload_data" "SAMLRequest"]] set SAML_Issuer_loc [string first "saml:issuer" [string tolower $SAMLdata]] set SAML_Issuer_start [expr {[string first ">" $SAMLdata $SAML_Issuer_loc] + 1}] set SAML_Issuer_end [expr {[string first "<" $SAMLdata $SAML_Issuer_start] - 1}] set SAML_Issuer [string range $SAMLdata $SAML_Issuer_start $SAML_Issuer_end] if { !([ACCESS::session sid] equals "" ) } { ACCESS::session data set session.saml.request.issuer $SAML_Issuer } } } when ACCESS_SESSION_STARTED { if { [info exists SAML_Issuer] } { ACCESS::session data set session.saml.request.issuer $SAML_Issuer } } Tested this on version: 11.6Show message while SAML IDP redirects an user to the SP
Problem this snippet solves: When an user gets redirected from a BIG-IP IDP to a SP the browser may display a white screen when the SP isn't responding right away. This happens when for example the SP needs some time to perform some user lookups or is just slow. This code snippet will alter the blank page and put a message on it. See the example below. Besides a message, you can also choose to display a CSS Loader. For more information on these CSS Loaders see: http://cfoucht.com/loadlab/ How to use this snippet: Create a new Virtual Server that will act as the IDP frontend. This Virtual Server will need a STREAM profile and the iRule below. This additional Virtual Server is needed to be able to modify the HTTP response of the Virtual Server that holds the Access Policy. Code : when RULE_INIT { # select one of the CSS Loaders # # These CSS Loaders are created by Camden Foucht # See: https://github.com/CamdenFoucht/LoadLab #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { } set static::saml_redirect_html { } #set static::saml_redirect_html { # # # # } #set static::saml_redirect_html { # # } #set static::saml_redirect_html { } #set static::saml_redirect_html { } #set static::saml_redirect_html { # } #set static::saml_redirect_html { } #set static::saml_redirect_html { } # you can also display a message. #set static::saml_redirect_html { Please wait while you are being redirected... } set static::saml_redirect_css { } } when CLIENT_ACCEPTED { virtual vs_idp_example_com } when HTTP_REQUEST { set match 0 STREAM::disable HTTP::header remove "Accept-Encoding" if { [HTTP::uri] starts_with "/saml/idp/profile/redirectorpost/sso" } { set match 1 } } when HTTP_RESPONSE { if { $match } { STREAM::expression "@ $static::saml_redirect_html
IdP Discovery for IdP Initiated SAML
Problem this snippet solves: This iRule enables IdP discovery for IdP initiated SAML for v12 and earlier. In v13 and later this is not necessary because IdP discovery for IdP initiated SAML happens by Issuer match in the assertion. IdP discovery is only needed if you have APM acting as SP and have bound multiple IdPs to it. How to use this snippet: Apply this iRule to the virtual server acting as a SAML SP. Set your matching criteria in the bindings, the iRule assumes session.server.landinguri is used, change as needed if you used something else. You must create a datagroup named saml-idp-matching, string type. The string is the referer header in the SAML assertion sent to /saml/sp/profile/post/acs. The value is the matching criteria used in the binding (ie: the landinguri used for SP initiated). Example datagroup entry: Example SAML binding: Code : #This iRule enables IdP discovery for IdP initiated SAML #This iRule is unnecessary in v13 and later because IdP discovery in IdP initiated SAML happens automatically by issuer ID in the SAML assertion. #You must create the saml-idp-matching datagroup for the lookup, string type, string is the referer URL and value is the matching criteria #You are assumed to be using session.server.landinguri as the matching criteria, if not, change it below when ACCESS_SESSION_STARTED { #Check if this request should contain a SAML assertion if { ( [HTTP::uri] equals "/saml/sp/profile/post/acs" ) and ( [HTTP::method] equals "POST" ) } { #Look up the referer URL in a datagroup and get the matching value set matching [class match -value -- [HTTP::header value Referer] equals saml-idp-matching] #Set that value as the value for the session variable used for IdP discovery ACCESS::session data set session.server.landinguri $matching } } Tested this on version: 12.1Webtop Return Without Reauthentication
Problem this snippet solves: By default if you hit "/" on a VS with a webtop assigned it will terminate the session and require reauthentication. This iRule will cause the user hitting "/" to be redirected to the previously assigned webtop without needing to reauthenticate if their session is still valid. Here are a few example scenarios this iRule helps with: 1. User goes to a webtop, leaves, and later tries to return 2. User performs SP initiated SAML auth, authenticates to the webtop VS but never sees the webtop, and later tries to go to the webtop directly 3. User leverages SAML autolaunch iRule for IdP initiated SAML, then later tries to return and get the webtop How to use this snippet: Apply to the virtual server hosting the webtop. Code : when HTTP_REQUEST { if { ( [HTTP::cookie exists MRHSession] ) && ( [HTTP::uri] equals "/" ) && ( [ACCESS::session exists -state_allow [HTTP::cookie value MRHSession]] ) } then { HTTP::redirect "/vdesk/webtop.eui?webtop=[ACCESS::session data get "session.assigned.webtop"]&webtop_type=webtop_full" } }
