I hope I am not being to dense but I don't know how to use phpoidc. I have downloaded phpoidc from https://bitbucket.org/PEOFIAMP/phpoidc. I have followed the instructions in the INSTALL file. Now that it it supposedly installed, how do I use it? There does not seem to be any documentation on this.
I just want to set up simple user authentication on my site. I am running CodeIgniter 3.0 rc. I primarily want to allow login with google accounts.
Are you talking about the OP side or RP side?
OP side should be quite self-explanatory as it is a stand alone thing.
RP side needs integration to your application.
The phpRp is just a sample implementation that uses these libraries.
What it does is to create an OpenID Connect request and process the call back to see validate the response. Then, typically, an application needs to associate the iss and sub in the ID Token to a local account: you need a mapping table for it. Once you are done with that, create a session and off you go.
Related
I was trying to setup OAuth workflow using the sample application as given here
However for some reason, after I enter my okta user Id and password, I never gets the control back on my call-back URL and application just hangs indefinitely.
However the normal Javascript Singn-in widget (check this link) with the minimal authentication does work and I get the control back to the redirect URL. But this is not for an OAuth2 workflow... which is completely useless for me. Because all it does is provide authentication service using Okta tenant app and it will redirect you to your App URL. This does not provide any authorization grant workflow or other OAuth2 complex workflow. May be useful for some application but not for enterprise app where you want to retrieve user profiles, and create a login session based on user profile data retrieved from OKTA.
So my question is why is the OAuth workflow not working using the PHP application that uses JS sign-in-widget? And why there are no instructions or warning on this page for this costly service (this is not free and many org is probably paying for this)?
I spent almost a day trying to setup my Authorization server as per the instruction given on this link, but nothing works. Any idea what must be going wrong ?
Does this entire example works only after contacting OKTA support to enable the Authorization server feature? Because, I also saw a documentation here that says that this is Early Access (EA) feature (and it is probably recently added in OKTA? Extremely frustrating experience).
BTW I sent email to their customer support to enable this Authorization server feature just in case if I am missing something. If this does not work then I will have to create my own OAuth2 server using Laravel 5.4 PHP framework, which is probably the quickest solution and 100% free.
I also tried to test the Authorization server setup as per the instructions provided here.
I was successful in getting the following end point working:
/oauth2/:authorizationServerId/.well-known/openid-configuration
But I am unable to get any scope and claims using api end-point:
/api/v1/authorizationServers/:authorizationServerId/scopes
So in short, I am so far unable to test my Authorization server to get my authorization grant workflow working.
Where can I look for some troubleshooting advice?
Is there another way to check whether I have configured my OKTA Authorization server properly?
I found out that the JS script provided for the PHP sample is not right for the workflow I am working on. So after changing that JS Script, things started to work.
Edit: Also please note that Setting up Authorization server is a new feature (It is Early Access feature) in OKTA. It is not enabled by default. So you need to contact OKTA support team to enable the Authorization service endpoint and functionality provided by it.
I am not so much in need of code help here, more advice on how I should handle this scenario.
I have a REST API built, using Spring boot.
I also have a simple Hybrid app that I need to deploy to users within the company - and clients who "buy in" to the API access. The users can be anywhere in the world, which means I never know what domain they will be on.
I am told that using the header below is bad practice :
"Access-Control-Allow-Origin":"*"
Given that I know the only point of access with our API should be this frontend app, but that I never know where the user of that app will be, or what network they will be on, how should I do this?
Tagging spring community here, even though this is not a spring centric question. This is because I am actually using Spring, and I guess that community will have solved this problem before.
I believe that this question is not about CORS exactly.
"Access-Control-Allow-Origin":"*" is OK since you need your API to be accessible from anywhere.
Even if you know all the Origins you need to allow, you should not rely on Origin header sent from the client as one can send any header.
Authenticate your users and you'll know whether the user can access the API or not.
Thanks.
I want to implement Single signon between Spring application and Netsuite using cas. Seached many things on net but nothing was fruitful. kindly help me on this with some links or documents.
Thanks in advance.
I just completed two SSO's in NetSuite for our firm. (You will find this under Setup>Integration>SSO) We ended up having NetSuite send a specifically crafted URL to our internal PHP intranet. The web app' there receives the incoming URL and does stuff on it, and the user gets what they need.
Forgive me for not knowing anything about Spring, but if you can run your web app' to receive an incoming URL (post), then you will create a new SSO object inside of your ERP instance, and pass the values that you need to pass to your web app' from there. Those can be built-in values that come right out the system (ie: "{entityid}") or these can be values that you create with a script, pass them to the SSO, then the SSO passes those to your web app'. You can "place" an SSO "object" on to a "custom Tab" on your "custom Form". Or you can create an entirely new Form. Or you can place your SSO in some other location. I chose to place ours on a custom Tab, as that was effective for our use case.
The only other two places you can "place" your SSO is on to a "Portlet" (say, like a custom panel on your Dashboard or similar) or a "SuiteLet" (which I havent done yet but am working on right now).
If you have any "bundles" installed in your instance, some of them have SSO inside of them, and some of them are "protected" and some of them are not, and the unprotected ones can be downloaded as JavaScript to your machine for examination, consideration, & emulation.
The help in SuiteAnswers is decent but doesnt give many working examples for your to adapt. The PHP Tool Kit has a working sample of an SSO inside of it & I highly recommend getting that, unzipping it, and reading all of those files, even if it has no table of contents, you can easily follow all the includes and references amongst those files.
If you have a specific follow-up question about something in there, please post, and while I'm an intermediate at it, I'll give it the ole college try to answer. And if you need anything past that, ping me.
Cheers.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D
Our company has a web application that is only used internally by our employees. We also have Google Apps Premier Edition. We would like to make it so our employees can log into our private web application using the Google Apps account that they already have.
Requirements: We want to display our own login form. We don't want to pass the email/password in plain text through the internet.
Which authentication mechanism should we use to achieve this?
Note: our application is written in PHP using Zend Framework (if that matters).
I would look into some combination of OpenID and your domain users (i.e. only let those at domain.com can log in).
Google API
They also have libraries for PHP and other languages that you can leverage to make this happen.
EDIT:
Some more info
When it comes to integrate Google Apps and an internally used private system, we simply have two options.
Use Google as the authentication center. Modify the private system to authenticate at Google's server. We could use OpenID or AuthSub. Check http://code.google.com/apis/accounts/docs/OpenID.html and http://code.google.com/apis/accounts/docs/AuthSub.html for more information.
Use the private system as the authentication center. In this case, we have to implement SAML protocol in the private server and configure Google Apps's SSO settings. Check http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html for more information.
It is easier to accomplish SSO with the first method since there's already bunch of OpenID libraries out there. But, as you described in the requirements, you want to use your own login form. So I guess you have to go with the second method.
BTW, if your private system has to get or set information from Google, you may want to use OAuth for authorization. See http://code.google.com/apis/accounts/docs/OAuth.html for more information.
Use the ClientLogin API, it does exactly what you're after: allow you to verify username and password. (the link goes to provisioning API doco but that is not relevant here)
Pro's:
you get to use you own login form
Cons:
you don't get SSO with Google Apps, i.e. users already in Apps will be prompted to login again (you didn't mention that as a requirement, but it seems a reasonable thing to want)
Google won't like you (they're trying to discourage ProgrammaticLogin.
you will get occasional CAPTCHA tests you'll need to show your users.
OpenID specifically prevents you from displaying your own login page, so if that's a hard requirements, Programmatic Login is really your only choice.
Going the SSO route let's you do pretty much anything, but may be a bit of overkill to take on authentication for the whole domain to make one app authenticate in a nicer fashion? If you really want to go down this route, check out SimpleSAMLphp.