We are developing a web application that has its own SignOn mechanism (login mechanism using username and password). The SignOn mechanism is implemented using a Web Application Filter)
The web application container is Apache Tomcat 6.0
The User may also choose to login through Shibboleth authentication. That is, to access our Web Application, the user may choose either be authenticated using Shibboleth, or using our own SignOn mechanism which is web application filter-based.
Is it technically feasible to support both Shibboleth Authentication, and a Web Application Filter based SignOn mechanism?
If it's feasible, from the Web Application Filter side, how do we check if a user was authenticated already by Shibboleth? Is there some Shibboleth Authentication token, or Shibboleth User session?
Thanks.
I assume that you refer to Shibboleth SP (the Service Provider component) and also that you will need Shibboleth IdP (an Identity Provider) to provide the actual authentication.
...And yes, it is feasible and the two methods can easily coexist.
When the user is successfully authenticated by Shibboleth SP (using the Identity Provider) it place the well-known session attributes in the HTTP request attributes and headers.
You can view the session attributes visiting:
https://your-host/Shibboleth.sso/Session
So, Inside your application you can check the presence and the value of those attributes like:
request.getAttribute("NAME_OF_THE_ATTRIBUTE_IN_SESSION")
request.getHeader("NAME_OF_THE_ATTRIBUTE_IN_SESSION")
Then, using Shibboleth attributes you can do the necessary operations to allow or deny the user authentication.
See this official wiki to understand how "Shibbolize" an Application and this for accessing attributes.
I would recommend to start reading from the start this clear and comprehensive wiki on Shibboleth SP and IdP installation and configuration.
Related
I have a working c#/dotnet Windows desktop application that does its work by hitting various web services in my web application. When the desktop application starts up, it prompts the user for username / password and then hits my login web service, which returns a session token.
I have a large-org customer with many users. That customer wants to provide authentication / authorization for my combined desktop / web application directly from their domain controller. They want single signon, so my desktop app doesn't prompt their users for usernames and passwords.
How can my desktop application retrieve a usable authentication / authorization token from Windows (maybe from the user's Security Principal object)? How can my web application validate that token so it can trust the desktop application and send it a session token?
(My web application runs in my environment, not in the customer's domain.)
With pure-web-app customers I do this successfully with SAML2 and Active Directory / Federation Services. The SAML2 dance gets my user's browser to POST a request to the customer's AD/FS server, which then POSTs a signed response back to my web app.
But I can't figure out how to do it cleanly from a desktop application. Any wisdom?
You can check this samples in github (by jelledruyts): Modern claims-based identity scenarios for .NET developers
It has samples of authentication and authorization using Azure Active Directory and/or Windows Server Active Directory Federation Services.
I suggest read this article Digital Identity for .NET Applications. It's a little old but is a good overview/review.
Tokens come in many different formats. For today’s .NET applications,
however, three kinds of tokens are most important. They are the
following:
User name/password token—This very simple token contains only two
claims: the name of some subject and that subject’s password.
Kerberos ticket—More complex than a user name/password token, a
ticket includes a subject’s name, the name of the subject’s Windows
domain, and other information. Kerberos tickets that are issued by
Active Directory also include an extension that contains security
identifiers (SIDs) that identify the subject and the groups to which
this subject belongs.
SAML token—The Security Assertion Markup
Language (SAML) is an XML-based language that is owned by the OASIS
multivendor standards group. Unlike the other token types that are
described here, a SAML token doesn’t have a fixed set of claims
defined for it. Instead, this kind of token can contain any claims
that its creator chooses.
As soon as the claims are available, they can be used by Windows, the
application, or both. The most common uses of claims include the
following:
Authenticating the user(...)
Making an authorization decision(...)
Learning about this user(...)
Kind of Authentication:
Domain Based Authentication (eg Kerberos tickets):
A domain-based application accepts only a single token format with a
fixed set of claims. One common example is a Windows application that
accepts only Kerberos tickets. This kind of application is easy to
create, and it works well inside a single Windows domain. The problem
is that this simplistic approach to digital identity is no longer
sufficient for many applications
Claim Based Authentication (eg. SAML tokens):
Unlike a domain-based application, a claims-based application can
potentially accept multiple token formats with varying sets of claims.
The token formats and claim sets that this application accepts are
determined by the application itself.
Identity Technologies
Active Directory (AD) Domain Services (full-featured directory service, token source for Kerbero tickets, etc)
Active Directory Federation Services (ADFS) (support for claims-based applications, token source for SAML tokens
Windows CardSpace
Active Directory Lightweight Directory Services (subset of AD services)
Identity Life-Cycle Manager (ILM) (synchronization between different identity stores)
Windows Authorization Manager (tools for RBAC - role-based access control)
Active Directory Rights-Management Services (RMS)
Because AD Domain Services implements Kerberos, the default token in a
Windows environment is a Kerberos ticket. To use this default, an
ASP.NET application specifies Windows Integrated Authentication, while
a WCF application uses an appropriate binding, such as NetTcpBinding.
In either case, the following figure illustrates how a Windows
application with clients in the same domain might use a Kerberos
ticket and AD Domain Services
First versions of AD FS only support SAML with web clients.
ADFS 1.0, supports only browser clients—a restriction that’s scheduled
to change in the technology’s next release.
Hope it helps.
I should preface this with the fact that I've never done this, so I can't give you exact code, but I can point you in the right direction.
You should be able to do this with ADFS and Windows Integrated Authorization (WIA). In a "pure web app", the browser sends the credentials of the currently-logged-on user during the authorization step. In your case, your desktop app needs to do everything that the browser would normally do. Either way, the setup on the web service side should be exactly the same.
In C# with HttpClient, this is the important part:
var httpClient = new HttpClient(new HttpClientHandler()
{
UseDefaultCredentials = true
});
Then, whenever your httpClient sends a request that is challenged with a 401 response, it will automatically resend the request with the user's Windows credentials. This is exactly what a web browser would do. So use that when you get the token.
You may have to send a user agent string in the request, since ADFS seems to limit WIA to certain agents.
Once you have a token, then use the token in your requests to the web service.
The key is that you're replicating what a browser would do. So if you have trouble setting up what the HTTP requests should look like, then access a GET request in your API from a browser and use the browser's dev tools to inspect exactly what the traffic looks like, and use that information to replicate the same request in your code.
I want to have own identity provider in my website. I don't want use another identity provider like google, yahoo and etc for OpenID connect (For registration of my website).
I think Shibboleth is good and stable solution for this require. But I don't sure about it:
1- Shibboleth is only identity layer and don't have any database for store users attribute, this mean, I should have another solution for store my user's attribute and using shibboleth only for SSO and authentication.
2- I can use shibboleth for both of the SSO/authentication and "user's attribute store"
First I have questions for you.
Do you want to use any other authentication provider for you application?
Do you want to give authentication/authorization to any other web site?
Do you have or will have multiple application which will need single point sign one ?
If the answer to any of above question is false then you don't need Shibboleth.
You need to first understand how shibboleth works. There are two main product in shibboleth Service Provider and Identity Provider. If your case is point 1 then you need SP, if your case is point 2 then you need idP and if your case is point 3 then you need both.
idP and SP are totally disjoint things. In case of you logging in into stackoverflow using google's account, google is idP and stackoverflow is SP.
idP manages authentication, so it will have the user database/data, So answering to your first question, yes shibboleth does not have any database to store user data and it is only identity layer. Or more precisely authorization layer.
Because SP is what that use that authentication to authorize some paths in its website. If you configure your SP in such a way that example.com/secure should only be accessible when user is authenticated in example2.com - authentication - then when user go to example.com/secure, shibboleth will redirect him to example.com/login (configurable in idP) and will only allow to access when shibboleth will have valid session.
Answering to your second question, Yes you can use it both ways but you should not because it is authentication/authorization software, it gives some attributes from idP to SP but it is always recommended to use that information and store it in our DB.
Edit (after reading comment)
So you definitely need SSO. It need not to have Shibboleth which is SAML based. Choosing a SSO technique is big thing and require lengthy answer.
I have used OAuth, LDAP, Shibboleth, SAML. I am using OAuth2 for my applications.
Please search for comparison between Shibboleth and OAuth2 and decide. This may help.
We have requirement of build .NET based plugin/component for enabling Authentication against multiple IDP providers like ADFS, Azure AD and Shibboleth based on DB configuration. i.e, depending on the configurable parameter the anonymous user will be authenticated against any one of the IDPs like ADFS, Azure AD or Shibboleth IDP.
Our application URL ("https://www.contoso.com/ProcessToken.aspx") will be registered as RP Identifier in all of the 3 providers.
We won't make any web.config changes for any of the providers.
At run time, User will access common page(Proesstoken.aspx) who needs to get redirected to the any of the Login page URLs at the provider (ADFS, Shibboleth, Azure) for Authentication based on User Organization. (For ex: User A to ADFS, User B to Shibboleth etc)
After Successful authentication at the IDPs the user needs to get redirected by the provider (ADFS/ Shibboleth/ Azure AD) to the RP Url registered.
In the redirected page (ProcessToken.aspx), we are planning to get the security token and decipher the claims required.
The main intention is to decouple authentication away from application logic and it should be extendable to other providers in future.
PS: Considered options like OWIN Authentication Middle Tier, .NET Component etc.
Need guidance on How and where to start.
Have a look at IdentityServer 3 which implements this multi-auth scenario or OWIN : ASP.NET MVC application with multiple authentication options.
The main point is that you use NuGet to download all the protocols you require and than use OWIN to pull them all in via app.use.
You can configure ADFS to have Claims Provider Trust with the other IDP's Owin will acknowledge the authentication. The difficult part will be reading the attributes from the tokens. ADFS under the covers in conjunction with the Owin framework use ws-federation, I have not figured out how to read the SAML.
What gets confusing is that at one time the answer was WIF but now that 4.51 has been released, WIF was moved into Owin. The documentation for a multi-tenant application is sketchy at best.
I am a little bit confused about the terms of authorization and authentication. I know what each term means but combined with different Single Sign-On services I've got some problems with a consistent terminology.
What I am confused about is that, for example, CAS ( Central Authentication Service ) is meant to be used for authentication AND authorizationk. For me authorization would mean, that there is a functionality in the implementations, so the server decides if the user gets access to a different service or not.
But as I've seen, for example in CAS, that authorization for them is only sending different user attributes to the service and it decides whether the user can access or not. But is CAS then really providing a authorization? Is this not just authentication and then giving some attributes to another service which then decides whether the user can pass or not?
tl;dr:
Is sending user attributes to a given 3rd party web service so he can decide whether the user gets a login session or not already authorization by the SSO service, or is it just helping the 3rd party service to manage authorization ( so the SSO service does NOT provide authorization, just authentication) ?
CAS is not an authorization service. it is build to support authentication with single sign on and it can not authorize anything, the only authorization part it can help u with is to send u some user roles as attribute and u can use those roles as `role authorization'. for more than role authorization u need to implement your own authorization system (maybe embedded in the application that is using cas as authentication?)
We have an existing Java EE application running under WebLogic and I want to authenticate a user programmatically as though the user was logged in via the existing web login process. That is to say, in the end, I want to have a valid session (cookie) that can be returned to the caller and later returned back the server without re-authentication. (This is to enable JAX-WS stateful Web Service calls).
We have a custom LoginModule that, when the user logs in via Forms Authentication, is eventually called via j_security_check. I guess what I'd like to do is to somehow get WebLogic to invoke that LoginModule on my behalf, ask me for the credentials, and yield an authenticated session and a valid subject etc. (i.e. all the JAAS goodness).
Is this a JAAS thing? Is there a WebLogic call?
You can do this using the HttpServletRequest#login method. This will trigger the same kind of login chain that would otherwise be executed if your used accessed a protected resource.
WebLogic security uses a security service plug-in (SSPI) architecture that allows you to implement security providers. Container (such as servlet) authentication is handled by authentication providers that use the SSPI. An authentication provider wraps a JAAS login module.
Writing and configuring security providers is extensively documented.
If you implement an authentication provider to wrap your login module and configure it for the WebLogic domain, it will be called automatically by the WebLogic security framework for all container authentication.