I'm trying to write a Perl-based web application, that uses Kerberos 5 Negotiate Authentication to authenticate its users. The Perl web framework I'm using is Perl Dancer, in its non-CGI, self-contained operating mode. I'm running this on the Fedora distro of Linux.
Negotiate Authentication can use existing Kerberos tickets forwarded from the users' browsers, or use regular Basic Authentication to allow the users to establish their first Kerberos tickets. The end effect of this is the sites that support Negotiate Authentication are seamlessly integrated into the SSO environment.
CPAN has the Authen::Krb5 module, which I suspect would be the foundation of offering Negotiate Authentication, however I can only find client-side modules on CPAN. These client-side modules can be used as a back-end for really simple Basic Authentication, or for establishing the first Negotiate Authentication ticket, but cannot perform Negotiate Authentication itself (ex. Authen::Krb5::Easy).
I have found an implementation for PHP here. The accompanying how to guide gives a good high-level idea of how Negotiate Authentication should work, and how a Negotiate Authentication library written for Perl (or any language) might be used in a web application. Ideally I would like to use a Perl library with a similar interface to this PHP one.
Does a Perl Negotiate Authentication server-side library exist?
What would be the best way to write one if none exist?
You mod_auth_kerb or mod_auth_spnego and read REMOTE_USER from server env. You're done.
I did some more searching, and basically all libraries implementing the server side of Negotiate/SPENGO/RFC4559 are written in C, and usually based upon Apache's mod_auth_kerb.
Though no Perl libraries surfaced, I did find one for Python 2, called PyKerberos. It appears to be well explained in the source (something severely lacking from other libraries), and, as a bonus, it seems this Python 2 module is widely available from distro package repositories (python-kerberos in Fedora).
Currently, it appears the best answer to my question is to call PyKerberos from Perl via Perl's Inline::Python module. This solution is probably slow (Perl -> Python -> C), but since my application doesn't have any serious performance requirements, it should be sufficient.
Related
Mongo C++ driver has two compilation option. From driver documentation:
--ssl Enables SSL support. You will need a compatible version of the SSL libraries available.The default authorization mechanism since MongoDB version 3.0 is SCRAM-SHA-1. If you want to use standard MongoDB authentication, you should compile with –ssl option for SCRAM-SHA-1 mechanism support.
--use-sasl-client Enables SASL, which MongoDB uses for the Kerberos authentication available on MongoDB Enterprise. You will need a compatible version of the SASL implementation libraries available. The Cyrus SASL libraries are what we test with, and are recommended.
I wonder about clients not using authentication (which is a typical scenario in which the CB-MongoDB connection is secured using other means, e.g. level 3 firewalling, or simply the user doesn't want it, for whatever reason) from the point of view of performance. I mean, it is fine that users wanting authentication pay a price for it (in terms of performance penalty of the SSL CB-MongoDB communication needed to authentication) but users not wanting authentication shouldn't be affected .
Is the driver clever enough so even having being compiled using --ssl and --use-sasl-client clients not using authentication gets the same performance than if the driver would have been compiled without these options?
Note: I know this is question about Mongo C++ legacy driver which is a legacy piece of software. However, maybe a similar one applies also to the new driver (assuming it has a similar option-based compilation configurability) so I understand that the question is meaningfull anyway.
I know Central Authentication Service (CAS) and Kerberos both could be utilized to authenticated for establishing the session.The two protocols involves at least three parties,and will create a Ticket Granting Ticket duration authentication,so which differences are there between CAS and Kerberos?
Anyone could help? Thank you!
[UPDATE]
#Fred said (please see reply below)
it(CAS) is a way to proxy authentication services like Kerberos or
LDAP on the Web.
However,JASIG states "CAS then generates a ticket and a transient cookie transmitted over SSL to be stored in Browser memory" (https://wiki.jasig.org/display/CAS/Extended+Authentication+Walkthroughs), so I guess CAS isn't just like a proxy because it itself can generate a ticket. Am I right?
Please shed a light on me, thanks!
CAS is not an authentication service in and of itself, but it is a way to proxy authentication services like Kerberos or LDAP on the Web.
At the time CAS was invented there was little support for kerberos in either the browser or the server. So CAS ( and Stanford WebAuth, and the one Duke wrote and ... ) all came up with various ways to emulate the kind of authentication service Kerberos provides using what was available in the browser. (i.e. stuffing things that look a lot like kerberos service tickets into browser cookies... )
Even now, kerberos support is not uniformly available in all browsers and all servers. Configuring your browser to do kerberos authentication via SPNEGO can vary from completely automatic to next to impossible. If you have a web based application, your best bet is to use something like CAS to do cookie-based authentication. A proxy service like CAS will work with any browser that supports cookies.
Kerberos does not support session key and only use algorithm verification。
As I understand it,
SPN is an authenticating tool for windows services.
Kerberos is a
user authentication service
SPNEGO-GSSAPI is the third party API to
be able to use those services.
SSPI : is the Neutral layer to send
request from SPNEGO to SPN service.
Am I completely lost?
Trying to figure out how it works but information, is either too precise or not enough.
Ok a more verbose answer:-
SPN - Service Principal Name. It is an identifier associated with each account in a KDC implementation(AD, OpenLDAP etc). Basically if your account acts as a service to which a client authenticates, the client has to specify "who" it wants to communicate to. This "who" identifier is the SPN. This is the strict definition. Many people often call the client name (UPN - User Principal Name) of a service as SPN. This happens when the service itself may act as a client( google the delegation scenario ). This is not strictly correct but widely assumed true.
Kerberos is a protocol for authentication. It is a name for a framework. It involves a third party server(called KDC or Key Distribution Centre) and involves a series of steps of acquiring tickets(tokens of authentication). It is really complicated so http://en.wikipedia.org/wiki/Kerberos_(protocol)
To some extent you got this right. GSSAPI is an API but SPNEGO is not. GSSAPI is technically agnostic to the auth mechanism you use, but most folks use it for kerberos authentication. SPNEGO is a pseudo mechanism, in the sense it declares an RFC for authentication based communication in HTTP domain. Strictly speaking SPNEGO is a specification but most folks also consider it as an implementation. For instance, Sun and IBM JDK provides "mechanism providers" for SPNEGO token generation but GSSAPI is used to actually call it. This is done in many projects(Tomcat as a Server is and example that come to the top of my head and one of the folks who answered this question developed it).
SSPI is an analogue to GSSAPI in windows. Its a different API which ends up doing something very similar to GSSAPI.
Not quite.
SPN simply means 'Server Principal Name' and is the AD or Kerberos slang for the service you try to authenticate against.
Kerberos is a user authentication service, more or less yes. It also provides security for network messages and calls between services.
SPNEGO-GSSAPI* is a kind of strange beast. GSSAPI (Generic Security Service Application Program Interface) is an API to (in principle) different authentication services, it provides negotiation of the mechanisms used. Often the only mechanism available will be Kerberos though. It is the usual API to attach 3rd party programs to Kerberos when you are on Unix (defined in various RFCs, for example RFC 2743 )
On the windows platform SSPI is the generic layer, so it compares to GSSAPI.
SPNEGO is kind of a strange hybrid. It is a mechanism to be used in SSPI, HTTP Auth or GSSAPI which negotiates another auth protocol (for example Kerberos or NTLM if you are on Windows), so it basically does the same thing GSSAPI does again in a different way.
Typical uses of SPNEGO are HTTP authentication to a windows domain, for example IIS uses it if you use 'Integrated windows authentication'. It is also used when you select the 'Negotiate' options for SSPI. See for example RFC 4559
Almost all of your understandings are wrong.
Here it goes:
SPN: A specific service-class is bound to a specific account, e.g. HTTP to www.stackoverflow.com => HTTP/www.stackoverflow.com#STACKOVERFLOW.COM
Yes
3./4. GSS-API (Unix)/SSPI (Windows): Mechanism neutral API to interact with. E.g, Kerberos 5, NTLM, SPNEGO, etc.
SPNEGO: It is one of many mechnisms supported by GSS-API/SSPI. It is actually a pseudo-mech.
single sign-on (SSO) for web applications (used through a browser) is well-documented and established. Establishing SSO for Rich Clients is harder, and is usually suggested on the basis of Kerberos tickets, in particular using a Windows login towards an ActiveDirectory in a domain.
However, I'm looking for a more generic solution for the following: I need to establish "real" SSO (one identity for all applications, i.e. not just a password synchronization across applications), where on client's side (unmanaged computers, incl. non-Windows), the "end clients" are a Java application and a GTK+ application. Both communicate with their server counterparts using a HTTP-based protocol (say, WebServices over HTTPS). The clients and the server do not necessarily sit in the same LAN/Intranet, but the client can access the servers from the extranet. The server-side of all the applications sit in the same network area, and the SSO component can access the identity provider via LDAP.
My question is basically "how can I do that"? More specifically,
a) is there an agreed-upon mechanism for secure, protected client-side "sso session storage", as it is the case with SSO cookies for browser-accessed applications? Possibly something like emulating Kerberos (TGT?) or even directly re-using it even where no ActiveDirectory authentication has been performed on the client side?
b) are there any protocols/APIs/frameworks for the communication between rich clients and the other participants of SSO (as it is the case for cookies)?
c) are there any APIs/frameworks for pushing kerberos-like TGTs and session tickets over the network?
d) are there any example implementations / tutorials available which demonstrate how to perform rich-client SSO?
I understand that there are "fill-out" agents which learn to enter the credentials into the application dialogues on the client side. I'd rather not use such a "helper" if possible.
Also, if possible, I would like to use CAS, Shibboleth and other open-source components where possible.
Thanks for comments, suggestions and answers!
MiKu
Going with AD account IS the generic solution. Kerberos is ubiquitous. This is the only mechanism which will ask you for your credentials once and just once at logon time.
This is all feasable, you need:
A KDC
Correct DNS entries
KDC accounts
Correct SPN entries
Client computers configured to talk to the KDC
Java app using JAAS with JGSS to obtain service tickets
GSS-API with your GTK+ app to obtain service tickets
What did you figure out yourself yet?
Agreed with Michael that GSSAPI/Kerberos is what you want to use. I'll add that there’s a snag with Java, however: by default, JGSS uses its own GSSAPI and Kerberos implementations, written in Java in the JDK, and not the platform’s libraries. Thus, it doesn’t obey your existing configuration and doesn’t work like anything else (e.g. on Unix it doesn’t respect KRB5CCNAME or other environment variables you’re used to, can’t use the DNS to locate KDCs, has a different set of supported ciphers, etc.). It is also buggy and limited; it can’t follow referrals, for example.
On Unix platforms, you can tell JGSS to bypass the JDK code and use an external GSSAPI library by starting the JVM with:
-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so
There is no analogous option on Windows to use SSPI, however. This looks promising:
http://dblock.github.com/waffle/
... but I haven’t gotten to addressing this issue yet.
I am new to the SAML world. I just installed Shibboleth SP and IdP, and made them work with each other. I am now trying to understand how everything works under the hood.
The question is: When we install SP for Apache on Windows, we can choose whether to install Shib Daemon or not. Can anybody tells me what is that used for? Is it optional to make SP work?
I have tried to google and searched old posts, but cannot find so much details. My understand is Shib SP is a module that runs on Apache(for my install), and it is responsible for:
Setting up trust connection with IdP
Handle request from browser, and redirect to IdP
Handle response from IdP and redirect to user's real application page.
It seems to me that Shib Daemon is not involved in these works. Did I miss anything or I misunderstood anything?
Thanks you so much!
I can explain how it works on Linux with ShibD and Apache, and I think that will be similar to the way it works on Windows.
The ShibD process itself is what processes all of the SAML 2.0 assertions. The assertions are received by Apache, so there is a mod_shibd module for Apache that talks to the ShibD process. This allows the ShibD daemon not to reside in the same process space as Apache. Thus, you do need the Shib Daemon installed, and you also need Apache and the mod_shibd module installed so that Apache can communicate with the Shib Daemon to provide SAML Web SSO.