I have successful setup Shibboleth IDP and SP with separate sub domains after digging on internet.
Example.
IDP : http://idp.url.com/
SP : http://sp.url.com/
Now,My Question is:
Is it possible to setup these IDP and SP with static IP? (Not a single example available on Web)
For Example:
IDP : http://192.168.100.240/
SP : http://192.168.100.133/
I have tried enough but not getting How to do this. If is it possible, what kind of changes requires for it.
At last Resolved IP based configuration,
While installing IDP use 192.168.100.240 instead idp.url.com entity name. (you can use any thing for organization scope/name(like jubinpatel.com even using IP) )
Only Take care about all certificates. here I made mistake, create new certificates if requires and config new/changed Password in property files.
Also if you going to change https ports, take care of same port related metadata file changes and tomcat/jetty server configuration.
Related
I am to be having a lot of problems, misinformation and confusion when attempting to find out the plausibility and viability of attempting this.
The requirement is for a remote client, accessing our website to be auto signed in with their Active Directory User account.
We have the option to setup a WCF service (or something similar) on their remote server for authentication purposes. Which from my little understanding is how this problem will be tackled.
So, my question after a little background is this.
CAN this be done, and HOW can it be done?
Instead of hosting a WCF service on their domain, I would look into installing ADFS on their domain.
You can change your website to accept security tokens from ADFS using the WS-Federation protocol. You can use classes from the System.IdentityModel namespace for that. An example of how to implement this in ASP.NET can be found here.
An alternative would be to use Azure Active Directory as your identity provider and have your client sync accounts to their AAD directory (or federate between AAD and ADFS). An example can be found here.
I installed Shibboleth service provider on localhost. I want to connect to shibboleth idp.
Error Message: No peer endpoint available to which to send SAML response
This is because I connect to IDP(idp.shibtest.org) from localhost?
samltest.id is good way to test shibboleth.
You cannot use localhost as SP to connect to remote IDp, that iDp won't find any SP to return to because localhost means it's own system so IDp would go in it's local system and find your given SP's entity ID. It won't find that entity ID so it would give such error.
These two approach may help you
Give your machine some public IP and try connect to IDp with that SP.
If you cannot make public IP, make both SP and IDp in your local system.
My this answer may help you.
I am designing a service to handle authentication across a number of hosted platforms. This service will need to be able to manage a number of different protocol for the users: LDAP, Shibboleth, no doubt others.
I was hoping to use the Shibboleth protocol internally and run the service as a Shibboleth IdP where depending on user category, nature of the protected resource, etc. the hard work of the authentication is passed on to the native LDAP, Shibboleth, or other server where the user already has an account.
It seems as though this should be possible, but I have not gotten sufficient clarity from the Shibboleth documentation to work out whether it is, let alone how to do it.
Is this possible? How do I do it? Useful documentation very much appreciated.
Shibboleth is not a protocol; it is the name of the software stak that uses the SAML protocol.
Shibboleth can authenticate users from LDAP, AD (and database via a JAAS plugin).
Documentation on hooking up Shibboleth to use LDAP for authentication and attribute retrieval is at: https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector
I have the following problem. I have an application (3rd party) that needs to connect to API via a proxy to request various data again and again. The application has a configuration section where the necessary details can be entered (the app then stores them in a config.ini file). However, one client doesn't like the proxy user/password to be stored in config files;
As I don't have access to the application's code, the simplest solution I can think of is something along the lines of a tunnel, i.e. write a simple app/script that would open a connection to the proxy, prompts the user for the username/password and then keep the connection open so that the application can access the proxy without needing username/password everytime. Is something like this possible? I mean I don't to create sort of full blown proxy that would sit between the app and the real proxy server, all I really want is something like a session so that once the IP is authorized to get through the proxy, the consequent requests go through as well.
I'd appreciate help and/or any suggestions for an alternate solution
p.s. the app is win32 only so the solution is for win32 only as well (ie no cygwin, etc.)
Thank you
Proxy credential caching typically works on a per-process basis, not a per-machine basis. So, having Application A make a request through the proxy rarely allows Application B to make a request without getting challenged.
If you can change the application's code, make a single request through the proxy using the desired credentials; e.g. make a HEAD request for your server's homepage. Most HTTP stacks (e.g. WinINET) will cache the proxy credentials for the life of the process.
I have a site i am working on that i would like to display only to a few others for now. Is there anything wrong with setting up windows user names and using windows auth to prompt the user before getting into the development site?
There are several ways, with varying degrees of security:
Don't put it on the internet - put it on a private network, and use a VPN to access it
Restrict access with HTTP authentication (as you suggest). The downside to this is it can interfere with the actual site, if you are using HTTP auth, or some other type of authentication as part of the application.
Restrict access based on remote IP. Just allow the IPs of users you want to be able to access it.
Use a custom hostname. Have it on a public IP, but don't publish the hostname. This means make an entry in your HOSTS file (or configure your own DNS server, if possible) so that "blah.mysite.com" goes to the site, but that is not available on the internet. Obviously you'd only make the site accessible when using that hostname (and not the IP).
That depends on what you mean by "best": for example, do you mean "easiest" or "most secure"?
The best way might be to have it on a private network, which you attach to via VPN.
I do this frequently. I use Hamachi to allow them to access my dev box so they can see whats going on. they have access to it when they want , and/or when I allow. When they are done I evict them from my Hamachi network and change the password.
Hamachi is a software VPN. Heres a link to Hamachi - AKA LogMeIn
Hamachi
They have a free version which works quite well.
Of course, there's nothing wrong with Windows auth. There are couple of (not too big) drawbacks, though:
your website auth scheme is different from the final product.
you are giving them more access to the box they really need.
you automatically reimaging the machine and redeploying the website is more complex, as you have to automate the windows account creation.
I would suggest two alternatives:
to do whatever auth you plan on doing in the final website and make sure all pager require auth
do a token cookie based auth - send them a link that sets a particular token in a cookie and in your website code add quick check for that token before you even go to the regular user auth
If you aren't married to IIS, and you need developers to be able to change the content, I would consider Apache + SSL + WebDav (aka Web Folders). This will allow you to offer a secure sandbox where developers can change and view the content without having user accounts on the server.
This setup requires some knowledge of Apache so it only makes sense if you are already using Apache or if you frequently need to provide outsiders access to your web server.
First useful link I found on the topic: http://pascal.thivent.name/2007/08/howto-setup-apache-224-webdav-under.html
Why don't you just set up an NTFS user and assign it to the website (and remove anonymous access)