Hello Everyone,

I have a bit of a cutting-edge problem that I'm not entirely equipped to
handle and would love some insight.

I am running Access Manager 3.2.x, and using it largely for SAML. We
have several services running beautifully. Like many educational
institutions, we also would like to use Google Apps for Education and

Our Google Apps for Education SSO setup was configured using the
standard instructions for NAM 3.2 (Cool Solutions, etc.) and it works
beautifully in all browsers. So far, so good.

The next step is to use SSO to log users into the Chromebooks. This is a
fairly new feature for ChromeOS -- I believe that it was introduced in
July, probably in CHromeOS build 35. In the course of our
troubleshooting we have updated ChromeOS on our devices to 38, which is
the latest.

So, that's the background: NAM 3.2 SAML SSO working with Google Apps. We
want to use the same SSO configuration to log users into Chromebooks
with the new ChromeOS SSO login screen functionality.

Right now, logging into the Chromebooks via SSO does not work. When a
user is redirected by the ChromeOS login screen to our NAM SAML page,
the user does see our login page and can put in his or her credentials
and hit "Submit". At that stage the NAM login form disappears and the
ChromeOS login process hangs.

I opened a ticket with Google on this issue, and we generated some logs.
The problem appears to be that the ChromeOS login screen has a higher
level of security than the Chrome Browser does. To wit: The ChromeOS
login screen does not like that the NAM login page has Javascript
attempting to modify the top level of the NAM frame.

Specifically, in the Chrome log we get messages similar to:
-[2232:2232:1021/105256:ERROR:CONSOLE(0)] "Unsafe JavaScript attempt to
initiate navigation for frame with URL 'chrome://oobe/login' from frame
with URL 'https://myserver:8443/nidp/saml2/sso?sid=0'. The frame
attempting navigation of the top-level window is sandboxed, but the
'allow-top-navigation' flag is not set.-

Okay, fair enough, the ChromeOS login screen does not like Javascript
messing with frames. The solution seems simple: Use a NAM login screen
without frames. The NAM documentation explains quite adequately that the
way to do this is to create a new login page from the 3.0 login
template. This I have done, with a little advice from the TTP Higher Ed
list (I needed to know how to explicitly specify the login page for a
specific contract -- i.e. use id=xx in the URL where xx is the contract
ID number).

It took me a little bit to figure out how to get a SAML URL that
specified the particular login page (
https://myserver:8443/nidp/saml2/sso?id=xx&sid=0 ), but I have now done
that. The end result as of now is that I can have Google Apps SSO target
a specific login page based on the frameless NAM 3.0 login page and
which otherwise acts as a proper SAML SSO page.

So what is my problem?

When the frameless page submits its login form, it submits it to
https://myserver:8443/nidp/saml2/sso?sid=0 , and that page DOES have
frames, and ChromeOS login still balks and gives the same error message.
As an experiment I messed with the Javascript on the NAM login page to
make it go to https://myserver:8443/nidp/saml2/sso?id=xx&sid=0 , which
still works but at some point in the login chain it still makes a raw
call to https://myserver:8443/nidp/saml2/sso?sid=0 and thus involves
frames in the whole business. And ChromeOS continues to dislike that.

Is it possible to do a SAML login from end-to-end using only pages
without frames in NAM 3.2 and later? Any ideas you have would be greatly

Kind Regards,
Johnnie Odom
School District of Escambia County

jlodom's Profile: https://forums.netiq.com/member.php?userid=1811
View this thread: https://forums.netiq.com/showthread.php?t=52004