Forum Discussion
Rusty_M_140798
Nimbostratus
NimbostratusUsing SAML for login vs F5 Login Page, but need the password for SSO profiles
I have a scenario where we are using SAML as our first point vs a F5 login page, see APM policy below.
The way this works is the user is re-directed to our SAML provider for authentication and if successful, allowed to pass along. The SAML Auth uses an AAA server which is a SP/IdP setup on the F5.
The issue I have is I am not able to use SSO profiles to auto login to apps hosted via the webtop because I do not have a password variable. (I am able to get domain and user)
This maybe a question for the SAML provider, but I am curious if there is a way to capture the password back from the SAML provider?
I understand this defeats the purpose of SAML in this case as the hole idea is not to send passwords but tokens.
Michael_Koyfma1Cirrus
Well, yes, SAML and the whole concept of federation are meant to reduce the need for passwords, but your use case, unfortunately, is still valid, as not all applications can use SAML. In your case there are three options:
- If backend application supports Kerberos for authentication, you can leverage Kerberos Constrained Delegation to perform passwordless SSO
- If the application supports the ability to extract user identity from a header, you might be able to modify it to trust the username from the header that APM would insert after authenticating the user
- You can use a SAML IDP(and F5 is one of very few, if not the only one that I can do it) which will allow you to pass the password as the attribute in the SAML assertion. It is secure because you would encrypt that attribute and thus only SP will be able to decrypt it and use it for SSO.
Rusty_M_140798Thanks Michael!
Can you clarify 3? I think you are referring to using F5 as the IDP vs a redirect to the actual SAML sever/SP. If that is the case I believe you have to use the F5 login page which is what we are trying to avoid. By using the page users that are on network would have to login vs being auto logged in as they are on a trusted network and trusted device.
- Michael_Koyfma1
No, I was saying that if F5 was an IDP(F5 can perform both roles - IDP and SP), then it could take user's password and securely encrypt it and pass to another SP as an attribute in the SAML assertion. The question is whether you control IDP or not - if IDP you're using is within your domain of control, you can consider whether you can deploy F5 in the IDP role instead of what you're using to accomplish your SSO goal.
Michael_KoyfmanCirrocumulus
Well, yes, SAML and the whole concept of federation are meant to reduce the need for passwords, but your use case, unfortunately, is still valid, as not all applications can use SAML. In your case there are three options:
- If backend application supports Kerberos for authentication, you can leverage Kerberos Constrained Delegation to perform passwordless SSO
- If the application supports the ability to extract user identity from a header, you might be able to modify it to trust the username from the header that APM would insert after authenticating the user
- You can use a SAML IDP(and F5 is one of very few, if not the only one that I can do it) which will allow you to pass the password as the attribute in the SAML assertion. It is secure because you would encrypt that attribute and thus only SP will be able to decrypt it and use it for SSO.
- Rusty_M_140798
Thanks Michael!
Can you clarify 3? I think you are referring to using F5 as the IDP vs a redirect to the actual SAML sever/SP. If that is the case I believe you have to use the F5 login page which is what we are trying to avoid. By using the page users that are on network would have to login vs being auto logged in as they are on a trusted network and trusted device.
- Michael_Koyfman
No, I was saying that if F5 was an IDP(F5 can perform both roles - IDP and SP), then it could take user's password and securely encrypt it and pass to another SP as an attribute in the SAML assertion. The question is whether you control IDP or not - if IDP you're using is within your domain of control, you can consider whether you can deploy F5 in the IDP role instead of what you're using to accomplish your SSO goal.
Pushpendu_BiswaHi Michael,
I have the same requirement. My IdP is on premise and I am able to send the password attribute in SAML assertion to F5 IdP but cant pass it to the backend app that requires NTLM/forms authentication. The question is how do I extract the password from the attribute and use it as session.logon.last.password? Tried to work with this iRule but didnt work.
when ACCESS_ACL_ALLOWED { set username [ACCESS::session data get session.saml.last.identity] set password [b64decode [ACCESS::session data get session.saml.last.attr.name.password]] } when ACCESS_SESSION_STARTED { if { [ info exists username ] } { ACCESS::session data set session.logon.last.username $username } if { [info exists password] } { ACCESS::session data set secure session.logon.last.password $password } }My policy looks like this:
Start --> SAML Auth --> SSO Credential Mapping.
- Rusty_M_140798
Hey Pushpendu, This is not possible the attribute "login.last.password" does not get populated when SAML is used as it does defeat the reason to use SAML auth.
The only way to accomplish this would be to use forms based via f5 page then add a SSO profile to each application in the portal passing the username and password for the different types of authentication required by the individual apps.
- Pushpendu_Biswa
Hi Rusty,
Thank you for your prompt response. But cant we inject this using iRule as some other variable and use Variable assign to map to login.last.password? I know in NetScaler we can do a traffic policy and then a profile by creating an SSO expression to pass the credentials from SAML to the backend apps.
However, if this is something not allowed by APM then its a different story.
- Rusty_M_140798
You can if you capture the password. If you do a saml redirect at login the user is actually logging into your IDP then redirecting back to the SP (F5) with a success token. The username and password never leave the IDP.
Pponte, I can see that working as long as your application trust the "token" provided by SAML to Kerberos. From what you listed you are saying once users pass SAML auth, allow them to access to applications if they are a member of, correct? This removes username/password from the equation but only works if your application will limit by group.