We want apps login against Identity Server with SAML. Apps will be separated in two domains. Apps in one domain share the sso, but not apps in the other. Example:
domainOne.com
app1
app2
domainTwo.com
app3
app4
When app1 login against IS, app2 is automatically loged via IS too. But app3 and app4 ask for the user/password against the same IS.
We try it with tenants in IS, but It seems app3 and app4 is loged in too when app1 login.
Are there a way to do that?
Thank you.
It seems to be that WSO2IS SSO session cookie (commonauthid) is NOT based on tenant domain. it is only unique for the server. It must be the reason for above behivor. Someone can see this as a bug. Someone would not. Because, It is SP's decision to allow the users from other tenant to login not. Users already authenticated with WSO2IS server and SP must decide whether allow to login or not.
However, this behavior can be seen when you configure your SP as SAAS applications in the WSO2IS. If you are not configured as SAAS applications, you can not login for different tenant. Because user's tenant domain and SP's tenant domain would be different. Therefore user must not be able to login. You must see error Service Provider tenant domian must be equal to user tenant domain for non-SaaS applications". If you have not configured as SAAS app and still user can login for different tenants, It is probably a bug in the WSO2IS.
However, following is some sample way to do this correctly within SP side.
Say, there are two app domains FOO and BAR
foo.com tenant contains the SPs from FOO.
bar.com tenant contains the SPs from BAR.
foo.com tenant contains users who can access SPs from FOO.
bar.com tenant contains users who can access SPs from BAR.
Say, user "bob" from foo.com access FOO app and bob can login with
SSO. Then SSO cookie would be set in to the "bob" browsers. SAML
Assertion received from WSO2IS contains the username as "bob#foo.com". FOO apps can accept the request as user is from foo.com domain.
Also, if bob tries to access BAR app using same browser... login
page will NOT be shown as SSO cookie is there, WSO2IS identifies the
authenticated user as "bob#foo.com" Then SAML2 response would be sent to BAR and username inside SAML Assertion would be "bob#foo.com" Then BAR app can reject this user as this user is from "foo.com" So user can not login to BAR apps.
Therefore SPs have the control of allowing users to login.
Related
I have a working implementation of SAML (OneLogin) within an enterprise architecture.
When a guest user arrives at my application they are redirected to the company login where they enter their username / password. After that the user identity is passed back to my application and we log them in.
However, I notice that in other applications within the company I do not have to login at all. Somehow the website "knows who I am" and seems to authenticate me automatically. I presume there is some form of certificate on my pc / browser which the other applications are passing to the SAML??
Can somebody tell me the technical term or process? Is there a process whereby I simply pull the certificate from the browser or PC and pass it to the SAML? I would like my users to be able to auto-login without entering their credentials.
Thanks
There's a number of mechanisms that support an "automatic" authentication like what you describe. In the Identity and Access Management (IAM) realm, we have all sorts of names for it, but many of us call that "seamless single sign-on (SSO)".
Within a corporate environment, I would suspect that you are dealing with a one of two mechanisms: Kerberos authentication (especially if you're a Microsoft shop and log in to a domain-joined machine on a daily basis), or your machine is in an MDM-type of system, which uses a machine- and/or user-based certificate (aka PKI) to authenticate the user or user/machine combination.
Within your enterprise, if there are other applications whose users are immediately authenticated to the application without entering their username and password, then you should talk to your IAM team or your Single Sign On (SSO) administrators to understand why that doesn't work for yours.
I will also say that it's possible that your security team evaluated what information your application offers (insider financials? source code? your secret recipe? credit card data?) and decided that they would still require the user enter their username and password to get access to the data. So when you go to your SSO admins to ask, if they say that it's intentional, you should feel free to ask why and who you should talk to about it.
After a LOT of research and testing I finally have the answer to this question, and it is incredibly simple!
In summary:
I have a working solution with OneLogin that sends me to a page like this:
https://sts.companyname.com/adfs/ls
The url is specified in the config: saml->config->idp->singleSignOnService->url
However, this page requires the user to enter their username and password and, instead, I would like the system to be fully seamless.
The solution, it turns out, is simply to hyperlink to the following url:
https://sts.companyname.com/adfs/ls/IdpInitiatedSignon.aspx?LoginToRp=https://mypage.com/saml/metadata
where "loginToRp" url is the url provided in saml->config->sp->entityID
The ADFS IDP Initiated Signon will connect to your metadata schema and automatically log the user in (without the user needing to provide any credentials)
NOTE: this only applies to intranet sites in a corporate environment
I have Postfix/Devocet Email server in a US location, and I would like to create a second email server in the India region but the domain name should be XXYYZZ.COM for both the servers. In the API we are finding the user's location, based on the location I will redirect the Emails.
If the user from US/India tries to create an Email box, India user mails need to redirect to the India server and US user mails need to redirect to the US server using a single domain user1#xxyyzz.com.
Bonjour Nanda,
I understand what you are looking for and it is perfectly possible via proxying which dovecot itself can do.
All you need is extra servers which will act as proxy in front of those you use as backend (US server and India server).
Since I have not much information about your backend, I suggest you read about:
Dovecot proxy (https://doc.dovecot.org/configuration_manual/authentication/proxies/)
IMAP+POP proxying (https://wiki1.dovecot.org/HowTo/ImapProxy)
LMTP proxying (https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/).
If the user from US/India tries to create an Email box
By explicitly setting a "host" attribute for each user in your passdb backend (at account creation), you should be able to redirect all requests to a specific host.
We want to provide seamless access for all our users to SP's like publishers. The SP's are independent and provide services to a lot of different companies, i.e., we each have independent IdP solutions.
We want it to work as if there were no authentication, i.e., the user find a link on the Internet and follow it. If the site provide special services (that we pay for) for our users we would like them to use our own IdP (but only for our own users) to authenticate them.
Our current SAML setup requires that the SP support IP-address recognition and/or use specific domain names, i.e., the user access a specific domain name or come from our IP-ranges so the SP knows which IdP to redirect to but if our user comes from any other IP-address and don't access a specific URL the system is lost.
How is this solved?
I think a cookie given by the SP every time the user gets authenticated (from our network which the SP recognizes) can solve this but is that the standard? And it is not really a solution as it requires that our users have visited them at least once from our network!
This isn't so much a SAML question as it is an identity provider discovery problem which isn't specific to the protocol. How is a publisher supposed to know / decide that a particular user should be redirected to your IdP via SAML or any other protocol? This isn't a tractable problem in a general sense. The publisher and you will need to agree on a contract between two entities (you and these publishers) when it comes to these special users / services.
One possible implementation of IdP discovery that doesn't involve domains or IP ranges is a dynamic lookup of the IdP based on the user's identity. User clicks a link, navigates to the publisher site and attempts to login with (for example) his identity of myname#mycompany.com . The publisher can then do a lookup of mycompany.com in their identity store of special users / services / IdPs and determine that this user should not be allowed to login with local (publisher-managed) credentials. Instead, the user should be sent to some 3rd party IdP via a SAML authentication request. The publisher can do this at the time of user login but before the user has a chance to enter their publisher-managed credentials, be it via your favorite AJAX technique or some other form of UI gratification.
The publisher could use a persistent cookie so that the next time this user comes to this publisher they'll know that this user "belongs" to a 3rd party IdP and redirect accordingly.
Bear with me please. I am a layman in web technology and have few simple questions which need simple language answers.
When we login using a username and password on any website, what exact connection/relation is established with the website server? Is it that the server stores the IP address of the user and allows the user access to certain tables from the server database for a short span of time and the regular query to the server keeps the 'connection alive'?
Thanks in advance..
A login system receives a set of credentials from the user, typically an identifier and a password. It could include what is called an authentication token, which is either generated by a handheld device (so you not only have to have id and password but the token generator; it's on the equivalent of requiring both the pin and the card at an ATM), or it's generated by combining the password with something else and returning an encryption result.
The login system, once it receives the credentials, compares them to what is stored on the credential database. In some cases the credentials are sent encrypted, such that even the login system doesn't even know what they are, all it does is determine if the encryption is correct. This would mean that even if someone was monitoring the communication channel they could not use it to fake a login later.
Now, if the credential is valid, one of two things happens. For a desktop application or general sign-on, the login program will transfer control to either the rest of the program (for an application), or grants access to the system (for a sign on). When the person leaves the application or signs off the system, then everything starts over.
For a website, the login program will send the user a cookie that another part of the website can read and determine the user was authenticated and their credentials passed. This continues until the cookie expires, or the user logs out. If the user logs out, the website sends a new cookie that says the former cookie is expired.
I am doing integration of SalesForce and OpenSSO with SAML. I have implemented steps mentioned on site
http://wiki.developerforce.com/page/Single_Sign-On_with_SAML_on_Force.com
There are two important use cases for SAML
Identity Provider Initiated Login, where a user starts directly at their identity provider, logs in, and is then redirected to a landing page at the service provider;
----This case working fine
Service Provider Initiated Login, where a user starts by clicking a link to the the service provider (e.g. a bookmark, mailed link, etc.) and temporarily redirected to the identity provider for authentication, then returned to the link they initially requested.
I am trying to implement 2nd Scenario :I am performing following steps
created my domain in SalesForce and deployed for Users
Added Identity Provider in Single Sign-On Settings
When I access My Domain URL. It redirect me to Identity provider login page.
After login to IDP it won’t redirect back to SalesForce page. It shows IDP success page.
How should I redirect back to SalesForce success page?
Salesforce's SP initiated SAML implementation is basically a hack - You need to first fire off an IDP initiated SAML response which contains an attribute called ssoStartPage. this points to your IDP login page. Once salesforce has seen this attribute it remembers it and uses it for future (SP initiated) requests. This post should hopefully help you (see point 3 at the bottom)