Forum Discussion
sbu1
Nimbostratus
NimbostratusSSO in HTTPS Portal Access Resource Items
Hi
I made a small FormBased SSO Configuration (URI Triggert) for a Website, which i'm publishing trough a PortalAccess on my Webtop. If i assign the SSO-Configuration to the AccessProfile, the SSO-Configuration triggers as soon as i click on the Link on the Webtop and Login works. But if i assign the SSO-Configuration on the PortalAccessResourceItem instead of the AccessProfile, nothing is happen if i click on the Webtop Link.
Because i need to publish more than one Website on the Webtop, assigning to the AccessProfile is no option. I also tried to workaround this Problem with a VirtualServer and assigning the SSO-Configuration to a simple AccessProfile from this VS, but then SSO only works every second time (i think because the SSO-Variables are not known in the second APM-Session on the first time).
I'm running out ouf Ideas :-( Does anybody know how to configure such a Setup?
Thanks in advance
sbu
Abed_AL-RCirrostratus
Hi Peter Hi sbu
I'm having the same problem
Did you got it work finally ?
Can you advise ?
Peter1Hi somebody,
Configuring portal access resources for SSO You can assign an SSO object as part of the portal access resource item. If you do not configure an SSO object at that level, you can use the SSO object at the access profile level instead.
I don't know how to get SSO object on portal access resource item configuration to work too. Does anyone has any idea? And what is the use case to do SSO object as part of the portal access resource item? Please give me feedback, at least ur opinion.
Thanks, Peter
- Kevin_Stewart
Employee
Variables used in APM don't really fit the strict local vs. global scope model. Session variables are global in nature (accessible throughout), but are protected by a unique identifier that only the session owner would have. In this rare environment, however, where you have one APM session inside of another one, they'll actually share a session. So any session variables that you create in the external (client side AAA) session will be accessible to the internal (server side SSO) session. If the internal policy requires session.logon.last.username and session.logon.last.password for a form-based SSO, then you need to set those values in the external access policy. If you have to perform any additional client side/AAA checks or lookups, then those too need also happen in the external policy. If, hypothetically, you had multiple internal portal VIPs/access profiles, and their respective SSO profiles required different values for username, domain, password, etc., then you'd need to create all of those as separate session variable names in the external policy and adjust the internal SSO profiles accordingly.
These are not global variables in the way that you may be envisioning a global variable. These are session variables, variables that are stored in a specific user session, that are accessible to both access policies.
- Kevin_Stewart
The best approach, in my opinion, is to point the portal resource at an internal virtual server with a simple access policy (start-allow) and SSO profile, the last thing you tried. The trick is that you have to set the internal SSO profile's session variables in the external access policy. So for example, if you were doing a form-based SSO on one internal policy (which might session.logon.last.username and session.logon.last.domain session variables), and Kerberos SSO on another (which would require session.logon.last.username and session.logon.last.domain), then you would need to set all of those session variables in the external access policy.
