Forum Discussion
AADSTS75011 by which the user authenticated with the service doesn't match requested authentication
thanks for your reply!
I am not a developer at all, but basically what you are saying is:
classes:PasswordProtectedTransport --> most probably this causes the problem
classes:Password --> this will work?
Is this correct? I will ask the developer to look futher into this.
Regards,
Josse
Yes, it will work and you can also share this article with him.
If still it doesn't work, let me know.
Regards,
Rishabh
- Josse HuizenJun 19, 2018Copper Contributor
Hello,
This is the code that is being used and is causing the error.
Note that some values have been anonymized.
Can you see anything wrong?
Regards Jossevar express = require('express');
var path = require('path');
var favicon = require('serve-favicon');
var logger = require('morgan');
var cookieParser = require('cookie-parser');
var bodyParser = require('body-parser');
var passport = require('passport');
var session = require('express-session');
var fs = require('fs');
var SamlStrategy = require('passport-saml').Strategy;
var kSSODomain = "";
passport.serializeUser(function (user, done) {
done(null, user);
});
passport.deserializeUser(function (user, done) {
done(null, user);
});
passport.use(new SamlStrategy(
{
callbackUrl: 'https://www.domain.com/sso',
entryPoint: 'https://login.windows.net/8888888-8888-8888-8888-8888888888888/saml2',
issuer: '8888888-8888-8888-8888-8888888888888',
cert: fs.readFileSync('sso-prd.cer', 'utf-8'),
signatureAlgorithm: 'sha256'
},
function(profile, done) {
console.log(profile);
console.log(done);
return done(null,
{
id: profile['nameID'],
// email: profile['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'],
email: profile['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name'],
displayName: profile['http://schemas.microsoft.com/identity/claims/displayname'],
firstName: profile['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'],
lastName: profile['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname']
});
})
);
var index = require('./routes/index');
var users = require('./routes/users');
function findByEmail(email, fn) {
vwapi.userFind(email, function(error, body) {
// console.log(body.result);
if (!error && body.result.substring(0,2) == "OK") {
return fn(error, body.data);
}
return fn(error, null);
});
};
var app = express();
// view engine setup
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');
app.use(logger('dev'));
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));
app.use(cookieParser());
app.use(session(
{
resave: true,
saveUninitialized: true,
secret: 'removedthis'
}));
app.use(passport.initialize());
app.use(passport.session());
app.use(express.static(path.join(__dirname, 'public')));
app.use('/saml2/', index);
//app.use('/saml2/users', users);
app.get('/saml2/login', (req, res) => {
res.redirect('/saml2/handlelogin');
});
app.get('/saml2/handlelogin',
passport.authenticate('saml', {
successRedirect: '/account/home',
failureRedirect: '/login'
})
);
app.post('/sso',
passport.authenticate('saml', {
failureRedirect: '/account/login',
failureFlash: true }),
function(req, res) {
var profile = req.session.passport.user;
console.log(profile);
validatedUser(req, res, profile);
}
);
function validatedUser(req, res, profile) {
}
// catch 404 and forward to error handler
app.use(function(req, res, next) {
var err = new Error('Not Found');
err.status = 404;
next(err);
});
// error handler
app.use(function(err, req, res, next) {
// set locals, only providing error in development
res.locals.message = err.message;
res.locals.error = req.app.get('env') === 'development' ? err : {};
// render the error page
res.status(err.status || 500);
res.render('error');
});
module.exports = app;- GlenEAug 01, 2019Copper Contributor
Josse Huizen Did you ever resolve this? Seeing the exact same behavior with a third party provider/app.
- Josse HuizenAug 01, 2019Copper Contributor
GlenE yes we had our 3rd party provider use a different SAML library and that did the job. There wasn't anything wrong with our Azure (configuration); it was something that was misconfigured/not working at the 3rd party's sP settings.