SSO login for APM Profiles

Can you try clear all sessions in APM and deleting all cookies in your browser?

Or even better test with an incognito browser 

I waiting for this morning so all sessions would be timed out.  Same result.  It seems to me that I would want a separate session for SAML as I have for OAuth?  It should behave as though there aren't on the same F5?

This a very straightforward setup and the error you are getting means that either you have wrong configuration or for some unknown yet reason your browser sends cookie from one policy to the other.

Could you post you vs config, policy config and HAR file will your are trying to access and getting error;

SO I was attempting to work with support on the last piece.. They don't seem to think it's possible.. At least not without paying for services ;-).   I just wanted to check to be sure we are doing the same thing.  All on the same APM Instance, I have my Oauth Profile, that references my Local SP which is Federating with my Local IdP.  So the problem is with Scope set to profile, that session started with a different profile that SAML doesn't know about.  And when set to Global, It knows about the other profile and errors that APM is already under evaluation.   This is one of the last responses I got from support: 

This our only supported OAuth guide, but there is no reference or guide to integrating SAML, so I would not have any feedback on what a working configuration or deployment would look like, or if it's possible to integrate SAML with OAuth:

OAuth Client and Resource Server
https://techdocs.f5.com/en-us/bigip-17-1-0/big-ip-access-policy-manager-oauth-configuration/apm-oauth-client-and-resource-server.html

It look like you may just have to use SAML OR OAuth but not both.

Since resolving the scope error results in a different error regarding using existing session cookies, I anticipate you would just need to ensure that users never connect to other VIPs or Access Policies, after they establish an APM session and have an existing Access session, as the design of APM will always prevent existing sessions from establishing new ones.

Hi BGill__CISSP__C​ 

I believe that something is wrong with your config
In fact I just created a lab with this exact config and works as should

this my postman used as oauth client

as you see i use "test.xxxx.xx" fqdn for my oauth policy

now my browser redirects my to testidp.xxxxxx.xx with SAML

after successfull authentication in SAML IDP policy, i get the access token to postman from OAuth policy

if you share your config i might be able to help more.

Just to be more clear below you can find the full authentication flow

As you can understand, if you have an active session in SAML Policy you will actually have Seamless SSO

I gave up on trying to use our on prem and decided it would probably work for a better SSO experience to use Entra anyways.  So I no longer have session issue.  I am however running into a problem now after consuming the ACS, it does redirect back to the OAuth profile.  It stays on the SAML profile and asks for credentials to log into the Webtop.   I am thinking that is a authentication issue once it get back and trying to authenticate again?   This is the 1s time I have used F5 as an SP, all of our exiting partnerships are IdP.  There aren't a lot options in the Authentication Config.. Just the Parntership, The ACS (which is none as we aren't using attributes, however they are sending some).  And Force Authentication is using - Use AAA server settings

Your current flow is not clear to me. 

You federated your oauth policy with entra using saml.

Where does this webtop comes from?

The VIP that I am using for the SP is the same as our IdP.   So as I think about it.  I think I may have missed a step.. Do I need a separate VIP/Profile for the SP?   My inclination would be that it needs to be on the VIP with the app, but I can't because the app is OAauth, so it already has an APM profile attached to the VIP. 

Hm ok, it makes some sense now.

Yes you cannot have the SAML SP and IDP in the same policy. 

Or better, you could have both in same policy it an IDP chaining scenario but not federated with each other.

If I am not wrong your initial point was to reuse existing session in you oauth policy.

So instead of having a login page in oauth policy you should replace it with SAML SP federated to entra id.

Am I missing something?

Why you just not replace the oauth login page with SAML?

That is exactly what I did.  But now the problem is consuming the Response.  As we mentioned, I probably need to setup a new VIP and SP Profile.   I don't have anything tying the SP Profile to the SAML Profile.  Just the assingment of the SP Profile in the SAML Auth box in the OAuth Profile.  So it makes sense it doesn't know how to consume it.  I think I just need to step back an find instructions creating a SAML SP Profile because now I am trying mulitpurpose our IdP profile with now changes.

But your oauth policy is different than your idp. And they are applied in different fqdns.

I still do get what you have done.

You just need to a saml sp config federated with azure and use it in your oauth policy.

Correct...   safeoauth.....com. and safesaml......com.  

I have a local SP config federated to azure, assignedin the oauth policy,  which is working.  I get the response back to safesaml.....com////acs  and it doesn't seem to know how to consume it so if falls back to my.policy

I think that I might know what is wrong.  They Auth Agent for SAML is the box in the OAuth Profile.  So I don't think that the safesaml is involved at all.  the safeoauth should have the acs uri provided by the auth agent.   If I am correct..  Going to change the ACS endpoint..  I don't think my safesaml should be involved in this at all..

Ok I see the issue now too.

Your federation is wrong.

You don't have to involve you saml idp policy in this federation at all. Your browser must return saml response to your oauth policy.

I thought this was clear before on my glow diagram

Yeah.. I see what you are saying.. Step 9 is the assertion going back to the oauth policy.. I just had it cross wired in my head ;-)