I am implementing a SAML SSO solution (using OpenSAML 2.0) for a service provider w/a complex environment. The platform contains multiple entities ('Sites') and there are separate logins for each of the sites (i.e., user#site1, user#site2, etc.). Additionally, the roles/permissions available w/in these sites can vary...
<SiteA>
<Roles>Role1, Role2</Roles>
</SiteA>
<SiteB>
<Roles>Role2, Role3</Roles>
</SiteB>
<SiteC>
<Roles>Role1, Role3, Role4</Roles>
</SiteC>
In short, is this too much to ask of a SAML assertion, given that SAML is generally defined as an authentication (vs authorization) mechanism? I haven't been able to find any good examples of an identity provider assertion (ADFS) that supports this.
Related
I'm trying to implement SSO with SAML 2.0 in a dynamic web app whose frontend and backend-for-frontend are outsourced and hence not maintained by my company. At the same time, this dashboard is to be used by external organizations so federation with SAML 2.0 is a requirement.
I've been reading a lot on SAML integrations but the vast majority of them involve making changes in the Service Provider itself (in other words, the web app) but, as I mentioned earlier, doing this would require making many changes in the outsourced codebase which – for business reasons – is a no go.
To avoid this, I would like to have an authentication service to handle as much SAML logic as possible. This way, we would be able to easily scale on the amount of identity providers and even SSO protocols in the future while minimizing the modifications on the frontends.
Find sketched sequence diagram here
After sketching the sequence diagram up, I realized I don't quite understand a few things yet:
Is the Service Provider receiving meaningful cookies once the Identity Provider successfully authenticates the user? If so, would it be wise to use them from the Service Provider and the Authentication Service to determine whether the user is authenticated or not?
If not, then the only possible way for a Service Provider to know whether a federated session is already established or not is to ask the Identity Provider every time, on each request it receives to a protected resource, right? Wouldn't this delay each request's response time too much?
Thank you!
We are just getting started with implementing ADFS authentication, however are still getting our bearings in terms of how to integrate it with other applications and systems.
From what I can tell, the main supported authentication systems for many of the applications we use (I am specifically interested in Blackboard authentication at the moment) are ones like Shibboleth, OAuth, CAS, LDAP and each application's own authentication implication.
What I'm not sure, however, is if (and where) ADFS falls under these categories. Conceptually, it seems like a type of "Central Authentication System" (CAS), but is more similar to Shibboleth (also a federated identity management system). Do some of the main categories of authentication overlap each other? From the documentation, I can see:
AD FS provides Web SSO to federated partners outside your organization, which enables their users to have a SSO experience when they access your organization’s Web-based applications.
The Central Authentication Service (CAS) is a single sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. The name CAS also refers to a software package that implements this protocol
Shibboleth is among the world's most widely deployed federated identity solutions, connecting users to applications both within and between organizations.
My main question is this:
Is ADFS a type of one of those main implementations (like CAS)...
or is it a proprietary version of something like Shibboleth, but can be used interchangeably...
or does it fall in a category outside of one of of one of those systems (and hence need to be handled through a manual or custom process)?
Just to clarify:
Shibboleth is an Identity Provider (IDP) aka Security Token System (STS)
OAuth is an authentication protocol
LDAP is an Identity repository
An IDP authenticates against a repository using an authentication protocol.
ADFS is also an Identity Provider (IDP) aka Security Token System (STS)
I've not seen the term "CAS" used in this context.
Shibboleth and ADFS perform the same function and are (in a general sense) interchangeable.
In practice, they aren't because Shibboleth only supports the SAML 2.0 protocol whereas ADFS supports WS-Fed, SAML 2.0 and OpenID Connect / OAuth 2.0.
Some additions/updates to the accepted answer from rbrayb a few years later:
Shibboleth IdP is the reference implementation for SAML and also supports CAS and OpenID Connect.
Shibboleth SP is the SAML service provider from the same project.
CAS (Central Authentication Service) is another web-SSO protocol like SAML; it's also the name of the reference implementation, which also supports SAML, OIDC, etc.
OAuth is an authorization standard.
SAML, CAS, OpenID, Kerberos and other SSO protocols are based on the concept of a Trusted third party.
LDAP happens to be a service in which, in a given organization, most or everyone already has an account with a password. There is nothing inherently special about it as a server to authenticate against. It could just as well have been a telnet server or web server with basic auth or a SQL server; in any of these cases, the application has to collect the username & password and pass those through to the back-end authentication service, unlike SSO protocols. (LDAP happens to provide a vendor-neutral, non-interactively-focused interface for the authentication, which is part of the reason it's often put to this task rather than the others.)
(I originally tried adding this as a comment but comments do not support the formatting I wanted.)
After reading about Microsoft's Claims-based identity, I don't understand what it brings more compared to OAuth (and therefore where is it better to use Claims-based identity rather than OAuth).
According to this Stack Overflow answer:
Claims-based identity is a way of decoupling your application code from the specifics of identity protocols [while] OAuth is a specific protocol.
This other answer claims that:
Claims-based security is required with OAuth
So it looks like:
Claims-based identity is more of an architecture while OAuth is a protocol.
Claims-based identity accepts multiple protocols, including OAuth.
OAuth uses Claims-based identity.
and obviously:
Claims-based identity can be used outside web applications,
Claims-based identity is Microsoft-oriented, which means excellent support in Microsoft products (such as SharePoint), but weaker support in other environments (such as a Python application hosted on a Linux server),
which means that there is a huge benefit of using Claims-based identity in corporate web, desktop and mobile applications within a company which relies heavily on Microsoft technologies and needs to provide authentication mechanism based on Active Directory and other providers, such as partner's OAuth providers.
Is my understanding of Claims-based identity right?
I cannot see anything incorrect in your part of the text.
You could also talk about claims as an: "signed attribute-name-value pairs". The issuer "claims" that it is correct. Attribute-value pairs itself pre-dates any new "claims" terminology and is widely used (under different names).
Yes, Microsoft is now fully Attribute-value pairs (claims if you insist on the nice word). Into the toe nails, even the native Kerberos token now has them. In the past it was only SIDs and privileges. In .NET everything is now ClaimsIdentity.
I am looking with Apache shrio framework. Looking at it authentication and authorization features can i build Identity server provider using shrio framework.
Is it possible to have features like,
Single Sign On
SAML support
Federation based on attributes
Do we need to write everything from scratch or shrio has some API's to handle such kind of features.
I read the documentation where they say about having SSO features based on Sharing of user session with multiple organizations . But i did not see any direct support API's to handle this.
To act as an IDP what shrio gives and what it does not support?
Please suggest.
Thanks,
Sohan
Shiro is a security layer that sits in front of your application. It is a security framework for a (SP) Service Provider that will issue an Authentication Request to your IdP (Identity Provider).
Open source IdP implementations that support SAML:
http://www.gluu.org/docs/
https://shibboleth.net/
This Stack Overflow question covers a way to use SAML to authenticate your user before they reach the application and provide the user's credentials as part of a http header.
Integrating Java Web App with SAML SSO
An alternative to installing and maintaining your own IdP.
https://stormpath.com/
The cost of developing, securing, and maintaining your own identity provider are likely much higher than paying a monthly fee.
I know that SAML can be used for user Authentication, but what about the permission levels a user has? Can it also be used for Authorization as well?
If not, what are the best alternatives for Open Source Authorization software?
SAML is a protocol that can be used for exchange of any information, including authorization-related "stuff". For example, in a very simple role-based access control scenario a SAML assertion issued by the identity provider can contain user's roles represented as attributes (or a single multi-valued attribute). The service provider can then extract the roles and use them to authorize access to some resource(s).
XACML is another protocol that is specifically geared to deal with some aspects of access control in an interoperable and declarative fashion. It is rarely used and it is considerably less popular than SAML.
oAuth is often used for authorization of access, especially in the REST world with APIs.
Both oAuth and XACML can coexist with SAML or be used independently.
SAML does not do authorization explicitly. It simply provides the attributes in the SAML token and it's up to the application as to how these are handled.
The same is true for WS-Federation.
For OAuth2, the "attributes" it provides are somewhat limited. And you still have to authenticate e.g. OpenID Connect.