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.
Related
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've a question about oauth2 and its suitability in this case. I've looked at the authorization flow, but that always seems to start the process from the 3rd party web app, not from the portal (auth server)...
My terminology...
1) We have Enterprise Portal system (e.g. SharePoint etc), let's call it portal.com
2) We have a 3rd party hosted web app, let's call it webapp.com
A user, already logged in (authenticated) in portal.com clicks a link on one of the portal pages that opens up webapp.com (my 3rd party, cross domain web app). I want to authorize the user to use webapp.com without the need for supplying any extra login credentials.
Questions:
a) is oauth2 the most common 'standards' based way to do this? Or have I misunderstood something.
b) If it is, what is the authorization flow? (I only seem to find auth flows that start from the user visiting webapp.com FIRST, then directing to portal.com to login, then redirecting back. But in my user story, the user visits portal.com first and is already logged in when they are linked to webapp.com).
Apologies if my terminology is poor - I am new to this area.
Cheers,
Ollie
Technically OAuth 2.0 has been created as Authorization protocol, but it is easily usable for Authentication (Identity Provider) as well and suits your situation rather well. You may however investigate OpenID Connect (OIDC) - which is an extension of the OAuth 2.0 exactly in the area of Authentication / Identity Provider.
If you have got a User Session on your Portal, then it is absolutely fine if you simply redirect to your WebApp and then the WebApp (which has no session yet) requests User Identity from the Portal by the means of OAuth 2.0 / OIDC. User would get extra 2 redirects without noticing anything but this way the login would also work fine if user bookmarks your WebApp and accesses it without first entering portal.com.
It sounds you are looking for a solution of single sign-on. If so, OAuth 2.0 (RFC 6749) cannot help you. OAuth 2.0 is a specification for authorization, not for authentication. It explicitly states as follows.
The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
Authentication deals with information about "who one is". On the other hand,
authorization deals with information about "who grants what permissions to whom". So, OAuth 2.0 is not the keyword for your case.
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.
Has anyone succeeded in configuring ADFS2 to use Live Id (or Google, Yahoo etc) as a Claims provider, and if so where did you get the configuration instructions (can you share them please)
I have previously manged to do this with ACS in Azure to connect to Live Id and ADFS, but would like use ADFS as the "HUB"
AD FS 2.0 itself does not allow authentication against a custom authentication store: it can only authenticate Active Directory accounts. (See this answer of mine for the official documentation at this point.)
A solution is suggested in an answer to another StackOverflow question, although the wording is a bit misleading. If you read the actual blog post you see that they add an extra STS. AD FS 2.0 has a 'Claims Provider Trust' for that other STS, and redirects to it (if the 'home realm discovery' is set up correctly). That other STS then performs the authentication in whichever way it likes (e.g., using a Google or Live account), sends a token back to AD FS, which then runs its claim rules.
So in that solution it is not AD FS 2.0 authenticating against an alternative store, but redirecting to an STS which authenticates against that store.
This is possible with a custom STS you federate your ADFS with.
The idea is to build an STS which itself uses OAuth2 to authenticate users and then (optionally) performs its own Active directory queries to find a user with the same email address and reads roles from the AD. Then the custom Sts returns all the claims to your application.
As Marnix points out, a hybrid approach is possible where the credentials are provided on the adfs page rather than the identity provider page. This is rather difficult as it involves setting up the wstrustfeb2005 endpoint on your sts. I have a six part tutorial on how to do this:
http://netpl.blogspot.com/2011/08/adfs-20-quest-for-customizing-adfs-sign.html
Nonetheless, the latter approach is much more difficult while exposing a passive sts federated with the adfs should not take you long time.
There will be login page via OpenID controlled by an extension. Can I ask for URL and pass in the extension and then pass it OP by use of extension? If no what kind of data can be transferred to OP from RP by an extension? If yes, how scalable it is, do I have to write separate code of each OP, or will the standard help me?
Also in unlikely case of XY problem - I need some sort of data that will allow me to authenticate OpenID user offline (after at least one successful online login). So if I was the one to provide login and password text fields I would be able to use user's password hash it and use for offline auth. And yes I need to use OpenID rather that other system, because this is the requirement. Sorry, It's kind of ugly problem.
I don't think you're supposed to pass a user id/password to the OpenID provider (or at least not password). The idea behind OpenID is that the provider takes care of the login, thus the web application utilizing OpenID will have no knowledge of the login credentials. OpenID provides you with some authorization information, such as the nickname, fullname, email, etc. This information, coupled with the OpenID of the user itself, should be enough provide you with unique authentication for that user without the need to have a password.
Your application needs to allow the user to go to the OpenID provider's page, enter their credentials there, and once authenticated you will get a response from OpenID indicating whether the authentication is successful and subsequently providing you with the user's information.
Update
Like I mentioned in my comments: the OpenID standard does not define a way in which you can send a password to an OpenID provider. So you can't use the OpenID standard in the manner you're envisioning it.
Update 2.0
Let's take myOpenID for example: in order to use myOpenID as an OpenID provider you have to register your domain with OpenID. Alternately, you can enable OpenID for your website by contacting Janrian (the owners of myOpenID), but I'm going to say you're still going to have to register a website with them. In either case, you must have a landing page on your domain, or on your website, which accepts an authentication response from the OpenID provider (in this case myOpenID). So let's look at what's required:
You must spoof a web browser when you're making the web request to the myOpenID provider.
In that web request, you have fill in the form which takes in the client's password (again, you have to spoof the client doing that).
You have to have a service of some sort running on a website registered with an OpenID provider (such as myOpenID).
You will have to send a message (HTTP) to the service that you're expecting an authentication response for a specific user (and provide it with a way to call you back when the user is authenticated).
That service will take any incoming authentication response from the OpenID provider.
The service will match that authentication with the user ID that you told it to expect in step 4.
The service will send your application the authentication response (callback).
You must accept the authentication response from that service.
The hardest part will probably be step 1 and 2, but there should be plenty of tutorials online that can show you how to do this (sorry I didn't have time to look up specific ones).
In any case, that's how I would imagine you may be able to do this, but it's far from trivial and I've never seen it done before.
Part of the reason why OpenID is so popular is exactly because people don't have to share their credentials with the service provider (i.e. your app), they only share it with the OpenID provider. The other thing you should think about is whether or not users will agree to use the OpenID in the manner that you want them to use it. In other words, one of the main reasons why people use OpenID providers is so that they avoid doing exactly what you're asking them to do: give you their password!
Update 3.0
You can register your domain with myOpenID by going to the new domain registration page: https://www.myopenid.com/new_domain