Howto extract SAML NameID from AuthnRequest

[hpr]

Hi Gurus,

I'm about to implement a SP-initiated SAML connection to our BigIP APM, set up as IdP, currently v15.1.2, eagerly awaiting some bug resolutions for the upgrade to 16.1.

I want to suppress the "login name" prompt on the f5 and just to ask for the password by extracting the login name from the NameID value.

IMHO, there's no need for the enduser to enter his name twice, first at the SP's and a second time at the APM login window.

Any clues?

Many thanks and best regards from Basel, Switzerland,

HP.

[Sajid]

autofill username, this may help you

https://devcentral.f5.com/s/question/0D51T00006lTl96/autofill-username-for-office-365-federation

https://devcentral.f5.com/s/question/0D51T00006i7ecT/using-saml-for-login-vs-f5-login-page-but-need-the-password-for-sso-profiles

[hpr]

Thanks Sajid,

The first link does what I want to do - but whith a different starting position.

I don't get the username with as a parameter, but as NameID (or subject, different field with the same content) of the SAML Authnrequest.

However, the idea of setting the username field readonly, is good! 🙂

So, follow-up question: Any irule-Magicians around who can help me to extract the nameID parameter?

(What I'd need is something like ACCESS::saml authn [value] but with the f5 as IdP, not as SP... 😉

Cheers,

HP.

P.S. For my own reference:

https://support.f5.com/csp/article/K07535385

[SanjayP]

sorry for the lame question,but if F5 is acting as IDP, shouldn't it have access to nameID already? It will generate the SAML assertion after authentication with domain controller. on F5, we would have to set AD query to retrive attributes from AD and set nameID accordingly (e.g. email/UPN etc).

[hpr]

Yes and no, SanjayP - you are way further in the process than my question... 🙂

YES: It should know the NameID, but

NO: Not from the AD/LDAP-Lookup, but from the SAML Authnrequest.

Elaboration: My process is:

1. User clicks on SP's login page on "authenticate with SAML" and is prompted to enter e.g. his email address
2. SP decides to send an Authrequest to our f5, as this is our IdP. THIS CONTAINS THE NAMEID AND THE SUBCECT ATTRIBUTES. Both contain the user's email address
3. WHAT I WANT TO DO NOW on the f5: Extract either of those Attributes, treat them (ie. cut the @domain part) and set session.last.username.
4. Show a login window with just a password prompt (as we already know the user name).
5. NOW do the LDAP authentication, LDAP lookup, and calculating the SAML Attributes for the SP. (Thats's where you think we are already - if I get your post correctly).
6. Issue the SAML assertion for the User for connecting the SP.
7. SP does - based on the provided SAML attributes - the authorization for his services and grants access accordingly.

So, my question goes to step 3, not to step 5 🙂

Cheers,

HP.

[SanjayP]

thanks. it makes perfect sense now 🙂 . Yes, I was talking about saml_subject in step#5.

There is similar discussion for auto populating user coming from SP.

https://devcentral.f5.com/s/question/0D51T00006lTl96/autofill-username-for-office-365-federation

but it appears authrequest doesn't have any attribute set if it's SP initiated SSO. Are you sure, you can see email address in authrequest?

ACCESS::saml authn [value] will not work, as that is triggered only when F5 generates the payload.

This would need to check first, how emailaddress is being sent (either any part of header, uri or payload) and write iRule to extract that, set custom session parameter with that and use in login page.

OR present F5 login page, with username/password field and take it from there. (which you are already doing it), but I understand it's not user friendly.

[hpr]

>Are you sure, you can see email address in authrequest?

Affirm, SAML Tracer shows it - even twice. 🙂

> This would need to check first, how emailaddress is being sent (either any part of header, uri or payload) and write iRule to extract that, set custom session parameter with that and use in login page.

IMHO it's part of the payload:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ...snip... <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">myEMAILAddress@hereWhereIAm.ch</saml:NameID> </saml:Subject> <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /> </samlp:AuthnRequest>

 But what I still am confused about: Am I really the first person on earth trying to omit that users have to enter redundant logon name twice? Simply can't imagine that this wheel isn't invented yet. 😏

[SanjayP]

Since SP and IDP sessions are totally diffrent and independent of each other, it would need custom rules built to extract the user. Not seen that's been implemented many places. We will keep the forum open for other to provide any inputs if there is any easy way to extract this.

On seperate note, how about modifying the page at the SP end to omit the field for user and just have sign in button, which will redirect the user to IDP and user would have to put it only once on IDP page? I know this isn't ideal option but just thinking out loud.

[Peter_Baumann]

Hi SanjayP,

I have an example for an SP, the Adobe Cloud.

It is handled the same way as the Microsoft Auth Page, you need to first specify a NameID (first.last@domain.com) and then the Authenticator recognizes the @domain.com and is redirecting then to the IdP.

Documentation from Adobe: https://helpx.adobe.com/enterprise/using/set-up-identity.html#set-up-directory

So how is it supposed to work when we have a button on this logon page?

So we have for every organization buttons on the logon page then?

I think this will not scale.

Do you understand now what hpr means?

In this example:

Open adobe.com logon page -> Enter first.last@domain.com -> Adobe does the redirect to the IdP for @domain.com.

What you mean is the way it is done with OAuth 2.0/OIDC where the big players like google/github/twitter etc. have bnuttons for login.

In SAML it is different solved, see the manual above from adobe.

I hope this helps to enlighten the question above a little bit.

Thanks,

Peter

[hpr]

>...how about modifying the page at the SP end to omit the field for user...

Difficult, see also Peter's Post above.

The SPs (about a dozen initially) are unlikely to develop such an extension just for us. 😅

But agreed: I'd need an iRule to extract this parameter. still wondering however that nobody has done this already. It seems so obvious to me...

[Peter_Baumann]

It seems that the only way to get the entered username in a SAML SP Initiated session is to read the referrer header and get the username parameter out of it.

See here:

https://devcentral.f5.com/s/question/0D51T00006lTl96/autofill-username-for-office-365-federation

and here:

https://devcentral.f5.com/s/question/0D51T00006i7iXISAY/apm-branch-rule-based-on-referring-url

The problem today is that modern browsers are limiting the data in the referrer header with the referrer-policy described here:

https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default

I already tried to set a "no-referrer-when-downgrade" Referrer-Policy header with a irule but APM seems to overwrite it.

So how can we change the Referrer-Policy header in APM to get to a solution above?

Thanks,

Peter

[Belanger__Yves]

Hi,

It is possible to extract the SAML authentication request passed in the GET query string. You need to inflate with an iRule LX. Like this :

https://devcentral.f5.com/s/feed/0D51T00007HPLCVSA5

# For a GET

set ilx_handle [ILX::init "Saml-plugin" "Saml-ext"]

# Try to base64 decode http query. Handle errors using catch.

#  Successful execution of b64decode by catch will return 0 and the output will be written to $SAMLdata

if {[catch {ILX::call $ilx_handle "inflate_b64" $requeteSAML} SAMLdata] == 0 and $SAMLdata ne ""}{

# base64 decoding succeeded

log local0. "SAML query string decoding succeeded : \[IP::client_addr\]: [IP::client_addr] \[SAMLdata\]: $SAMLdata"

} else {

# base64 decoding failed

log local0. "SAML query string decoding failed"

}

if {$SAMLdata ne ""}{

set SAML_Issuer_loc [string first "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]

log local0. "DEBUG SAML GET - issuer extracting : \[IP::client_addr\]: [IP::client_addr] \[HTTP::method\]: $methode \[PATH\]: $path \[SAML_Issuer\]: $SAML_Issuer"

}

For the authn request with a POST, you can do it like this : 

https://devcentral.f5.com/s/articles/apm-saml-idp-sp-issuer-extraction

Yves

[hpr]

Thanks,  ,

That looks promising, we'll go for it and report. 🙂

Cheers,

HP.

[Belanger__Yves]

Hi hpr,

Before you spend a lot of development time into it, you can validate the content of the SAML Authnrequest in the browser with SAML Tracer.

Yves

[hpr]

Check - we actually do know what's in there, as we defined the origiinal data. 🙂

Though the process is a combination (or rather: a sequence) of two SAML authentications, it's a little tricky.

https://www.edulog.ch/sites/default/files/2021-06/Grafik%20Architektur.png

But then, we have an excellent engineer at our fingertips. Right, Peter? 😄