паспортна стратегия за внедряване на стратегията в nodejs - node.js, удостоверяване, passport.js, passport-saml

Използвам passport-saml за удостоверяване. За това инсталирах

npm install passport passport-saml --save

И аз създадох IDP, използвайки този блог Auth0.

Инициализиран паспорт и определена стратегия за saml

app.use(passport.initialize());

passport.use(new passportSaml.Strategy(
{
path: "/login/callback",
entryPoint: "https://qpp1.auth0.com/samlp/bZVOM5KQmhyir5xEYhLHGRAQglks2AIp",
issuer: "passport-saml",
// Identity Provider"s public key
cert: fs.readFileSync("./src/cert/idp_cert.pem", "utf8"),
},
(profile, done) => {
console.log("Profile : ",profile);
let user = new Profile({ id: profile["nameID"], userName: profile["http://schemas.auth0.com/nickname"] });
return done(null, user);
}
));

И тук са маршрутите

app.get("/login",
passport.authenticate("saml", (err, profile) => {
// control will not come here ????
console.log("Profile : ", profile);
})
);
app.post("/login/callback",
(req, res, next) => {
passport.authenticate("saml", { session: false }, (err, user) => {
req.user = user;
next();
})(req, res, next);
},
RouteHandler.sendResponse
);

Сега това работи добре, но имам няколко въпроса

1) Какво прави issuer означава в saml стратегия

2) Защо трябва да използвам passport.authenticate в две URL адреси. Не разбирам защо се изисква това /login/callback поискване. И дори контрол няма да дойде /login искане ", в което съм преминал passport.authenticate метод?

Каква е логиката зад това? Това полезно ли е при всеки сценарий?

Отговори:

Просто завършихме изпълнението на много наематели с паспорт-saml. Чрез нашия цикъл на изследване, тестване и развитие ние открихме следното:

1. "емитент" изглежда се насочва към EntityID в SAML заявления за искане / отговор.
2. Определянето на автентичността на GET / входът ви даваЗадействан от СП поток способност. Едно AuthNRequest ще бъде изпратено до IdP. Потребителят ще (или вече е удостоверена) и тогава IdP ще направете обратно повикване към крайната точка за потребителски услуги на потребителското твърдение. в вашият случай POST / login / callback удостоверяване. Съобщението / крайната точка за вход / обратно повикване е потокът SAML, стартиран от IdP.

За да научите как да се интегрирате с нашето приложение,ние започнахме с само инициализирано от IdP поток с обратната връзка с ACS. Първият ни клиент, с който се интегрирахме, беше успешен. Първият въпрос, който те зададоха, обаче, е кой URL да използваме за потока, започнат от SP. :-) Бях в състояние да накарам SP-инициирания поток да работи скоро след това.

Аз проверих това като използвам Developers Salesforce и SSO Circle като тест IdPs.

Надявам се това да помогне.