I have portal A for which I've implemented SAML authentication with an SP (Azure AD). In portal A, I will show some screens from Portal B as Iframe.
Both portal A and portal B uses SAML based authentication from the same IDP (Azure AD).
Situation here is users login into Portal A and when tried to access pages where Portal B screens are shown as Iframes, they have to initiate a SAML login again (However they are not prompted to enter their credentials now
as they are already logged into Portal A using SAML authentication)
I was initially under the impression that when Portal A is authenticated against IDP, this will establish an SSO against all the portals which uses the same IDP for authentication. But now I understand that it is not how it works.
Is it possible to achieve SSO for all SP's which uses the same IDP for authentication when the user has successfully authenticated himself with one SP need not be prompted to login for all other SP's using samle IDP's?
There is an isPassive option in the SAML authentication request that allows the SP to check whether the user is authenticated at an IDP without any interaction with the user, regardless of the status (i.e. authenticated vs. unauthenticated). See https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf section 3.4.1:
IsPassive [Optional]
A Boolean value. If "true", the identity provider
and the user agent itself MUST NOT visibly take control of the user
interface from the requester and interact with the presenter in a
noticeable fashion. If a value is not provided, the default is
"false".
A SP could use that in an iframe that does not display to the user to find out whether to pop the "Login" button or not. If the user is authenticated a SAML response will be returned without bothering the user and an application session can be created. If the user is not authenticated, the SAML response will indicate that and the "Login" button can be shown.
This does rely on the fact that the SP knows which IDP to ask.
There is no standardized way to logon the user to all SPs in one go but the IDP could implement such functionality in something like an enterprise portal that launches iframes to the SP with IDP-initiated-SSO SAML responses.
Related
While SSO is enabled for an organization, can an API account still use Legacy Authentication (username/password still being used for this account) on behalf of a user that has SSO enabled?
Our company wants to transition to using SSO for all user accounts (except possibly the API account). Currently, we use DocuSign's Legacy Authentication header (X-DocuSign-Authentication) to send envelopes on behalf of users and create sender views for them. Both of these actions involve using our API account's username and password for authentication on behalf of a user.
I've read this post that says:
If you're using Legacy Header authentication, your application won't
be able to authenticate as users who have SSO Login enforced. Until
you're able to implement one of the OAuth workflows, users who need to
use your API integration will need to have their Login Policy set to
allow them to login with a password.
Does this mean that any user account that will be sent on behalf of them will need to have SSO disabled while the Legacy Authentication header (and API account using username/password) is being used?
In addition, we are trying to avoid having every user separately authorize the application to act on their behalf. This post seems to mention there is a way to avoid that. Both the Authorization Code Grant and JWT Grant state that you must get your user's consent. We want to avoid this since we have 100's of members and staff additional staff added frequently.
Optimally, we would like to keep the API things as they are. If we can't or shouldn't, what changes do we have to make?
If SSO is enabled, a user can still authenticate via their DocuSign password, and thus Legacy Header auth will still work. If SSO Authentication is made mandatory via Login Policy settings, the user cannot authenticate with their DocuSign password, and Legacy Header auth will break.
If your authenticating "system sender" user has SSO optional, the SendOnBehalfOf header can be used to impersonate anyone on the account, regardless of the other user's Login Policy settings.
If you have a Claimed Domain, you can grant Admin consent so that all users with email addresses under that claimed domain (current and future) will not be required to grant individual consent for JWT impersonation. More information on that is available here: https://www.docusign.com/blog/developers/oauth-jwt-granting-consent
Should I Create only one client and all my applications must connect to the identity server using it or there is configuration should I do to make it work?
Identity Server is Web API, grant type is "resource owner password".
Each application is a client. But whether you should use the same client_id is up to you. Personally I use different client_id's for each instance of an application. This helps me to identify the instance and allows me to use different secrets per instance. And I think that the client_id has to be unique when you are using refresh tokens.
SSO is something you get for free when you use OpenId Connect (oidc). It works because of a cookie on the IdentityServer website:
When a user has to log in, the user is redirected to the IdentityServer website where (after succesful authentication) a cookie is set, containing information about the identity of the user.
When the user is returned to the client (after succesful authentication) the client will also set a cookie. As long as this authentication cookie is available, the user will be logged in.
When the user needs to log in again, because the client can't authenticate the user (anymore), IdentityServer will try to identify the user with the information from the cookie on the IdentityServer website and (if succesful) automatically sign in the user, skipping the login form.
But it seems that your setup has nothing to do with oidc. When you say that IdentityServer is a Web Api then this suggests that the user is not redirected to the IdentityServer to login, meaning that there is no opportunity to set a cookie.
And Resource Owner Password Credentials (ROPC) is an OAuth2 grant type. This suggests that the user performs the login on the client.
In order to enable SSO, the user has to login on the IdentityServer website. While ROPC is still possible, you'd better use one of the recommended grant types.
Authenticate to Webapi, using oauth provider (FB etc) client side only (HTML5 /JS phone app).
This is a tricky one,
So I can authenticate to our webapi using a username and password, using js from a HTML client, passing username & password as parameters over HTTPS we can set the user to authorised so they can access additional controller(s) for DB updates etc, so far so good bear with me.
I can authenticate to FB, using MVC and set the user to authorised.
I can do the same with HTML & JS client side (hooray), now how would I then authorise the controller, OK I get the users email from FB, so what, anyone could pass that. Suppose I could redirect to a MVC page (from the client) and then set auth on the controller(s) that way, but that's just not good (sending the user out the app, or a pop window).
What's the best method to authenticate the user from the client and authorise webapi controllers at the same time securely, do I have to re-direct the user to a mvc page and do it that way, how are other's handling this for phone apps / phone gap / intel xdk ?
The method apparently is, example facebook, but process is the same for any oauth provider ,
obtain access token by getting user to sign in/on.
Verify Token is genuine using server API (in FB's case graph API)
Client is happily logged in, until access token expires.
On expire(2 hours is the default), redirect user to login again, app is known it should authenticate without signing in again, unless user has revoked authorisation on your app.
here's a link on how to handle expire access token (examples are PHP)
Not exactly elegant, but it is what it is, and I thought It was only for super geeks!
Sorry to answer my own question
My ASP.NET MVC 4 application is protected by SSO (OAM) with an ISAPI filter running on IIS. When a request to my application is received, it is intercepted by ISAPI filter and redirected to SSO. User has to login at SSO and after that he is returned to my application.
The username of authenticated user (via SSO) is shared with my application in HTTP Request Headers.
Request.Headers["username"]
What I am trying to achieve is- after SSO authentication, setting FormsAuthentication within my application for username = Request.Headers["username"]. This way SSO remains transparent to my application and Identity of user is available in HttpContext object, plus, I (developer) could effectively utlize Authorize attribute for specific roles.
To achieve this- I hookup into Session_Start(), read Request.Headers["username"], Set FormsAuthentication cookie. And I get this SSO user Forms-Authenticated for my application.
But my problem is when I logout (FormsAuthentication.Signout), I redirect it to another page inside the application, which triggers a new Session (I can see Session_Start triggering when this happens)
Am I doing the right thing- FormsAuthentication after SSO? And if not, why not and then how do I make my application aware of SSO authenticated user?
It's entirely reasonable to use FormsAuthentication cookies to track the logged in user in your application after they have been authenticated using a Single-Sign-On provider. You don't show it but I'm hoping that you are also getting some ticket that you can use to verify the signed in user out-of-band with the SSO provider and not simply trusting the username header.
What you may be seeing, however, is that the user is not signed out from the SSO provider when you sign them out of your application. Because of that, as long as they have a valid cookie for the SSO provider, they will remain signed in, i.e., the user will get automatically bounced back to your application from the SSO provider without any required authentication.
That's unfortunate, but normal.
If you truly want the user to be signed out, you'll need to make use of the centralized logout functionality. I haven't worked with OAM, but it appears that it does support this: http://docs.oracle.com/cd/E21764_01/doc.1111/e15478/logout.htm
I had to explicitly kill the session inside Session_Start if requested URL is logout URL. And then with next request (like from logout to login page again), it generates a new session and runs smoothly.
protected void Session_Start()
{
if (!Request.IsAuthenticated && !IsSignoutURL)
AcceptSessionRequest(); //process local authentication
else if (IsSignoutURL)
RejectSessionRequest(); //kill the sessions
}
For background on how SSO passes authenticated user's identity to my application, read my comment to tvanfosson's post.
The post remains opened for a better idea.
Currently I have a code modules which contains code necessary to authenticate user credentials and it includes AD users validation also. now I have a requirement to auto logging in without prompting the user to enter username and password if the user browses the application from company's network domain.
Can it be done via Single Sign on?if so how to implement it?
I believe the easiest way would be to use Integrated Windows Auth and ensure your computers are connected to the domain, and then the computers are set to have your host in the "Intranet" zone in IE, therefore your credentials would be passed. If this isn't an option perhaps take a look at ADFS or OAuth where you can implement SSO across many sites using Cookies, Tokens, Claims, headers, etc.
Thanks!
http://technet.microsoft.com/en-us/library/cc754628(v=ws.10).aspx
yes, you can implement sso via cookie, if you have cross domain request in iframe in IE browser, please remember to add P3P in http response header when set cookie