Authenticate transparently

[Rodrigo Santiago]

Hi Guys, 

Is that possible to authenticate a user transparently in an IDP? 

My cenarius is that:  We have 27 states in my country running 27 diferent applications. The company decided to developed a central system to manage one specific resource (the most important).

When a user makes a login in that local systems (not with saml, but his own authenticate process) and want to fill that specific form, he is redirected to the central system, with his attributes.

Each state is an IDP that answers for each user.

For now, we cant change the way users authenticate in each system (forcing use idp auth), but once logged in, i need to authenticate this user transparently in my IDP, and so, the central system that provides a central resource (SP) can see that.

In a attempt, we tried to call sspmod_core_Auth_UserPassBase::handleLogin($idAuth, $username, $password), but we need authState to do that, and of course, this breaks the rules.

Is there a way to handle logins (authenticate) from external, i mean, not from browsers (request protocol), but from a internal API code, once the user is already logged in another system ?

Thanks in advance

Rodrigo

[Nate Klingenstein]

Rodrigo,

There is a way in the SAML 2.0 specification, isPassive="true" for
authentication requests. In practice, it won't always be honored.

You would have a really hard time iterating through each of the IdP's
on each attempt. You would need to cache the user's selection somehow
at the central system or in an intermediary.

The externalization of authentication like that is literally the
problem that SAML was designed to solve. You could issue a SAML 2.0
AuthnRequest using ECP or similar if you have a central system to do
it, but then the central system will get access to all the credentials
when it makes each call. If the browser is going to do it, redirects
in an IFRAME using SAML 2.0 are probably your best shot, but you have
to be careful of rules in browsers that are there to prevent phishing
or credential theft.

Rules around setting usernames or other security-sensitive information
are usually there for a good reason. Not always, but usually. If you
need to undo one of those assumptions, that's a tripwire. I would be
careful about this.

It's not a solution, but maybe it helps explain the problem,
Nate.

[Peter Schober]

I'm not claiming to understand your use-case (how much of that is
inventing SSO protocols and matching software, how much is merely
about deploying standard SAML, etc.), but anyway:

* Rodrigo Santiago <trump...@gmail.com> [2016-08-28 00:54]:

> Is there a way to handle logins (authenticate) from external, i
> mean, not from browsers (request protocol), but from a internal API
> code, once the user is already logged in another system ?

If the browser is not present at the (SimpleSAMLphp) IDP how should
SimpleSAMLphp know for whom to assert what data?
So if you're talking about using SimpleSAMLphp as a SAML Identity
Provider implementing the OASIS SAML Web Browser SSO Profile then the
browser will need to be present at the IDP at some point, in order to
present *something* to SimpleSAMLphp in exchange for a SAML assertion
that the browser then can relay to the SP, as per the specification.
Ordinarily that "something" is some form of credential (such as a
username and password) but it could also be any other mechanism (a
custom auth source, e.g. checking for the presence of a custom cookie
or whatever) that allows to clearly identify the subject.

SSP can certainly be used as an IDP in a transparent fashion (i.e., no
visible UI interaction) if it's being used as "downstream" client to
an "upstream" SSO protocol/system. But you can't replace
"authenticating the subject present in a browser" with "nothing".

If all you want is some code that generates xmldsig-sigend XML as per
the SAML specs -- triggered by custom code of your own, fully
unrelated to the SAML protocol -- you're free to salvage parts of the
SimpleSAMLphp code base, of course, as long as you adhere to its
licence requirements.
-peter