Forum Discussion

Stan_Ward's avatar
Stan_Ward
Icon for Altocumulus rankAltocumulus
Feb 15, 2018

Assigning SSO profiles to different Portal Access items on a full Webtop

I have a webtop that displays an array of portal access objects based on APM's authentication and authorization (v12.1.2). There is an SSO profile assigned to the APM profile, but many of the portals link to apps that require a different SSO profile.

 

On the portal access object, there is a single resource with a host name matching the Application URI, and a path of '/'. A different SSO profile is set here for those apps that can't use the default profile.

 

It appears that the new profile is not assigned. APM Debug logging shows it attempting (and failing) to match against the URI list for the default SSO, not this app's SSO.

 

I know that the individual SSO profiles are good, because I can change each one in for the default, and the apps that want that profile do SSO correctly. The rest go to double logons.

 

How is this supposed to work?

 

4 Replies

  • It may be worthwhile to attempt to build a simple test profile for the specific app in question, assign the SSO profile to it, and then use that to obtain some debug information.

     

  • Sso profile assignment is like that:

     

    • when forwarding to pool members, sso profile must be assigned in access profile
    • when working with portal access resources, sso profile must be assigned in portal access resource items. The sso profile in access profile is not used.
  • I have. If the problem profile is assigned as the default, that app works. Any single profile can be assigned as default, and the app expecting that SSO profile does SSO correctly. But the SSO profile specified in the resource is never used, as indicated by the debug comparisons of URIs that only exist on the default profile. So, I have concluded that the resource assignment SSO profile is not taking effect for some reason.

     

  • I have the same issue and tried with /* , but its still not working. It is not considering the SSO profiles which are bound to resources.