- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2019 12:04 PM
We just installed the Vendor Risk Portal.
We currently have Service Portal and our Instance as well.
Both SP and the instance works correctly for checking SSO, and directing the user based on role. But some reason Vendor Portal isn't challenging for SSO.
I see several articles about redirecting or disabling the Vendor Portal page, which makes me believe something is turned off on ours?
Any ideas on what I'm missing? Shouldn't the SSO Challenge on Vendor Portal as well?
Solved! Go to Solution.
- Labels:
-
Vendor Risk Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2019 11:33 AM
This is actually caused by an ACL. The users do not have read capabilities on the UI Page. I thought this was fixed in a London patch, but I may be mistaken. Search your ACLs for name is content_redirect. There should be one where the operation is read and the type is ui_page. Check the roles on that ACL and make sure that your vendor users have a role associated to this ACL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2019 09:51 PM
You're most welcome. 😅
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2019 07:48 AM
Hi Shiva,
According to my BA and PM, this is just a standard our client has to make sure everything goes through their Global Portal. So indeed, we need to turn it on somehow.
I noticed this message of yours:
I also noticed this article:
https://hi.service-now.com/kb_view.do?sysparm_article=KB0719767
And this one:
https://community.servicenow.com/community?id=community_question&sys_id=7ac21f9adb5d6380d6a102d5ca96...
All of these make it sound like SSO on the Vendor Portal page is turned on and that you should be able to turn it off somewhere. But some reason, our's is off. And we want it on.
Nobody seems to talk about how to enable it.
Thanks!
Dirk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2019 11:01 AM
Almost have it working.
But some reason, when it is the Vendor Contact role signing in, we get this error.
But a non-user or an ITIL user do not get this error. The SSO works fine and directed correctly to the page they need to go to.
Interesting, if we remove the “content_redirect.do” from the url in the browser, it actually shows the Vendor logged in and sent to the proper location of /vdp
=======================================================================
Current code in the SpEntry Script Include
/**
*
* Service Portal sample script include to indicate
* 1. which login page should be used
* 2. the starting page after the user is authenticated
*
* Script is configured using system properties
* PROPERTY VALUE
* glide.entry.page.script new SPEntryPage().getLoginURL();
* glide.entry.first.page.script new SPEntryPage().getFirstPageURL();
*
* functions can return a path or null if no overrides are necessary
*
**/
var SPEntryPage = Class.create();
SPEntryPage.prototype = {
initialize: function() {
this.logVariables = false; // for debugging
this.portal = "/sp/"; // The URL suffix specified in the sp_portal record
},
/***
*
* Referred to by property: glide.entry.page.script
*
**/
getLoginURL: function() {
// When requesting a page directly (eg: /problem_list.do)
// The platform session_timeout.do sets the login page to welcome.do
// Since we are handling the login, clear that value
var session = gs.getSession();
var nt = session.getProperty("nav_to");
var sPage = session.getProperty("starting_page");
if (nt == "welcome.do")
session.clearProperty("nav_to");
if (!sPage && !nt)
session.putProperty("starting_page", gs.getProperty("glide.login.home"));
// Send the user to the portal's login page
var portalGR = new GlideRecord("sp_portal");
portalGR.addQuery("url_suffix", this.portal.replace(/\//g, ""));
portalGR.addNotNullQuery("login_page");
portalGR.query();
if (portalGR.next())
return this.portal + "?id=" + portalGR.login_page.id;
// Send to the a default login page
return this.portal + "?id=login";
},
/***
*
* Referred to by property: glide.entry.first.page.script
*
**/
getFirstPageURL: function() {
var session = gs.getSession();
this.logProperties('before', session);
var isVendorContact = false;
var gsRole = new GlideRecord('sys_user_has_role');
gsRole.addQuery('user', gs.getUserID());
gsRole.addQuery('role.name', 'vendor_contact');
gsRole.query();
if (gsRole.hasNext()) {
isVendorContact = true;
}
if (isVendorContact) {
session.clearProperty("login_redirect");
return '/vdp/';
}
// has roles and is not a Service Portal page - go to UI16
var nt = session.getProperty("nav_to");
var isServicePortalURL = new GlideSPScriptable().isServicePortalURL(nt);
var redirectURL = session.getProperty("login_redirect");
if (user.hasRoles() && !redirectURL && !isServicePortalURL)
return;
// user may have logged in from a frame, the /login_redirect.do page will bust out of it
if (!redirectURL) {
// redirectURL is nav_to
// if nav_to == "welcome.do" then use starting_page
var sPage = session.getProperty("starting_page");
if (sPage && nt == "welcome.do")
nt = sPage;
// Avoid a redirect loop to the home page
var ep = gs.getProperty("glide.login.home");
if (nt) {
if (ep == nt)
nt = null;
}
// PRB726860: if page is still welcome.do, go to glide.login.home preserving frameset
if (nt == "welcome.do") {
session.putProperty("nav_to", ep);
return;
}
session.putProperty("login_redirect", nt || "true");
return "/login_redirect.do?sysparm_stack=no";
}
session.clearProperty("login_redirect");
var returnUrl = this.portal;
if (redirectURL && redirectURL != "true") {
var spUrl = new GlideSPScriptable().mapUrlToSPUrl(redirectURL);
returnUrl = spUrl ? this.portal + "?" + spUrl : redirectURL;
}
this.logProperties('after', session);
if (!this.logVariables) {
gs.log('redirectURL: ' + redirectURL);
gs.log('User: ' + user.getName());
gs.log('is internal: ' + (!user.hasRoles()));
gs.log('returnUrl: ' + returnUrl);
}
return returnUrl;
},
logProperties: function(beforeOrAfter, session) {
if (!this.logVariables)
return;
gs.log('SPEntryPage: Redirect ------------------------------- ' + beforeOrAfter);
gs.log('session.starting_page: ' + session.getProperty("starting_page"));
gs.log('session.nav_to: ' + session.getProperty("nav_to"));
gs.log('session.login_redirect: ' + session.getProperty("login_redirect"));
gs.log('gs.fURI: ' + session.getURI());
},
type: 'SPEntryPage'
};
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2019 11:33 AM
This is actually caused by an ACL. The users do not have read capabilities on the UI Page. I thought this was fixed in a London patch, but I may be mistaken. Search your ACLs for name is content_redirect. There should be one where the operation is read and the type is ui_page. Check the roles on that ACL and make sure that your vendor users have a role associated to this ACL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2019 01:45 PM
Thanks Tim!
That helped.
Now at a point that Non-Users get Challenged / Itil Users get Challenged, but the Vendor Contract folks are not getting Challenged, but they can login and get directed to /vdp correctly.
So almost there.