anybody know is possible to use Persona for SSO purposes for cross site login which are sub domains of the single domain ? I do no find this useful feature in documentation.
thanks.
If all of the services are within a single domain (e.g. service1.example.com, service2.example.com, etc.), you could set a cookie on the top-level domain directly (example.com) and then all services could use the same session since they would all have access to that session cookie.
So one way to do this would be to redirect users to login.example.com when they click the login button on any of the other sites (service*.example.com). That login service would use Persona to ask the user to login and then it would set a cookie on example.com.
This strategy is of course not specific to Persona, it's a common way to get SSO between internal services within a company for example.
Related
I am creating a website that contains a bracket system for a Rocket League tournament. I have set up OpenID for Steam, so that handles PC users. However I am trying to branch out to the console communities. Is there a way I can use OpenID to allow a user to sign into my website with their PSN login?
I mainly just need their ID to keep track of their scores, but if I can get a
PSN API to work with an OpenID login it would be fantastic!
Thanks in advance?
See:
http://www.programmableweb.com/api/psn-sign
This may be what you need:
This API allows people to use the Playstation Network SignIn for their
own sites. If a developer's site URL is allowed by Sony, they can set
their site as the returnURL by GET. This allows them to bypass Sony's
official External PSN Sign In page. The site forwards to a developer's
site on a successful sign in with a sessionId by GET. There is no
official public API to convert the sessionId into a user specific
value (like the PSN-ID). The API converts a valid sessionID into a
proper PSN-ID.
You didn't say what did you try so far so I don't know it you already tried that or not.
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
There are plenty of questions here where someone wants to load an OpenID provider's login page in an iframe rather than redirecting and having the provider control the entire look & feel of the login page. For very solid security reasons (primarily anti-phishing) this is a big no-no, prohibited, and most OpenID providers refuse to load within an iframe.
I have been presented with a situation where OpenID is being used within a single organization's set of web sites and applications. The OpenID provider has a whitelist of RPs and will only respond to those RPs. There is a desire to extensively customize the login page at the provider based on which RP sent the user to it. (If there are strong security arguments against doing this as well, I'd like to know about them as well.)
A proposed solution to this is to simply allow the RPs to present the login page in an iframe, so they can put whatever design around the login box they want. In this scenario only the "Username" "Password" fields and "Login" "Forgot Password" "Register New Account" buttons would be hosted at the Provider, the rest of the page would be at the RP and still have the RP's address in the title bar. Not optimal, yes, but the argument is that "it's a different subdomain, but the same 2nd level domain, so it's still okay."
I don't understand how this could be the case - having very different login pages for different applications still leaves users more vurnerable to phishing and other attacks. Am I incorrect in this conclusion? Every question on SO about this appears to be about using an external or public Provider, and the counterargument I'm encountering is that those concerns don't apply in a private Provider limited to sites on the same domain.
The general concerns about having OpenID within an iframe do have some validity even if you role your own provider. If any of your components are vulnerable to script injections there's a risk that they could compromise your users credentials since you could access iframe data from the parent window.
The normal recommendation to redirect (optionally in a pop-up) would limit this risk since the attacker now need to inject into the OpenID login page where you presumable have no script injections flaws.
Two years further on and I do not think that this is currently considered to be a bad idea, specifically because there is an OpenId Connect specification (currently at draft 21) which is detailing the process by which an iframe should be used to enable a RP to communicate with an OP in an iframe.
http://openid.net/specs/openid-connect-session-1_0.html
I don't know how long it is until this becomes ratified, but it does show that this is under consideration as a valid approach for managing sessions in a RP.
I need to work out a way to setup the validation of the users of a web application before they've actually arrived at the site. That is, someone browses to a url, enters a username and password which is then validated against a db or whatever. They are then automatically redirected to the real web application, on a different domain out across the internet, which is passed the details of the user and which then lets them through to the site without asking for the credentials again. And this must be done as securely as possible.
What are the options available for this sort of problem?
Thanks,
What you are describing is a typical use case of intern-domain web authentication. There are multiple ways to do it,
If both domains belong to the same application/company, you can just do your authentication and then pass some token/secret to the other domain in your redirect. The other domain can drop another cookie to maintain the session. This is practically how it's done between different domains all popular websites. For example, flickr.com uses yahoo.com to login.
You can use Identity Federation if the domains are closely related (partners). Most popular mechanism to achieve this is through SAML.
OpenID can also be used (That's how you arrived at this site) if the sites are loosely connected. OpenID uses arcane login URL so it only makes sense for tech-savvy users. The regular user may easily get confused by its complicated login process and consent page.
OAuth is an authorization scheme. It's not designed for federated login but you might be able to use it.
Look up OAuth or OpenID.
We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).