I need to create a some SAML 2.0 assertions, and I'm having trouble finding what the XML should really look like. Most of the documentation seems to be about using particular tools, not about the messages. I've got the schemas, with a plethora of possibilities, but I can't find an example of what the relevant messages actually look like in practice.
The business rule says: in order to create a shared identity, the user tells system A their username and password on system B. System A needs to communicate this info (along with some demographics) to system B. System B validates the information and passes back a unique identifier which can then be used to refer to this user.
Could someone give me an example of what SAML 2.0 assertions would look like to carry this information?
FWIW, I'm using C#, and need to pass the XML around in ways which preclude using a 3rd-party tool.
I'm not sure your use case is quite what SAML 2.0 does.
What you describe as your business rules actually looks like a use case for identity provisioning, not access management.
Standard SAML 2.0 use cases focus on one party asserting identity (the identity provider) and the other party (or parties) relying on those assertions (the service provider). Assertions carry what's called a name identifier, use of which is agreed ahead of time between the identity provider and the service provider.
These name identifiers can be pretty much anything, but they broadly fall into two categories: transient and persistent. A transient name identifier is only useful in the context of the current session (and essentially only says, "I know who this person is") and tends to be used to protect the identity of the principal while allowing privileged access of some type. A persistent identifier can either be opaque (in a similar way to how OpenID is used to access SO) where the asserting party can repeatedly verify a principle's identity without disclosing their identity while maintaining a dynamic but stable shared identifier between the asserting and relying parties or more substantial, such as an Active Directory UPN (which can be pre-agreed ahead of time).
When it comes to passwords, as you mention in your question, the service provider (relying party) never sees the users password. The service provider hands the user over to the identity provider with an authentication request. The identity provider sends the user back to the service provider with a response, which in the case of successful authentication contains an assertion about the identity of the user in the context of the relationship between the identity provider and the service provider.
In context of your question, the big thing is that SAML 2.0 does not provide a way to either create the local "application" user account or link that local user account to a federated identity. This is simply not the problem SAML 2.0 tries to solve.
Now, back to your business rules...
It looks to me like what you're trying to do is either account linking or registration - I would approach it like this:
User visits application, clicks a button to use identity from the identity provider
The application produces an authentication request and directs the user to the identity provider, carrying that authentication request
The identity provider either logs in the user or reuses an existing identity session if the user has one. The IdP produces a response message containing an assertion about the user. In your case this assertion should at minimum carry a persistent name identifier. The identity provider directs the user back to the application, carrying the response message.
The application processes the response message. If a mapping entry exists for the persistent identifier passed the user is recognised from that mapping and logged in as that local application user. If no mapping entry exists the user can be asked to locally log in, and on successful local login the mapping entry can be produced, or a user account could be automatically created and the user could be asked to enter additional information (names, email addresses, etc.) The "corporate" use case would be that no automatic account linking or creation is allowed and that the mapping must exist ahead of time.
As for the content of the messages...
The OASIS Security Services Technical Committee has a zip file download available with extensive documentation of the parts of the XML schema, including examples. It's also well worthwhile reading the protocol and profile documentation, as these describe the flow of messages between the parties involved in the identity conversation.
There are a large number of presentations floating around that I found very useful. Specifically, SAML v2.0 Basics by Eve Maler helped me start realising what problems SAML v2.0 was trying to solve. This presentation includes examples of that assertions look like. There is an updated presentation and links to additional resources on saml.xml.org.
I'm not sure if any of this is going to help though, as your use case does not seem to be what SAML 2.0 is trying to do. You can add attributes and extensions as needed to requests and responses, but I can't see many identity providers doing anything with those attributes and responses.
Related
Suppose I have a working REST API for my product.
I want to give access only to developers who sign up to this product. Also, there will be several plans available so certain parts of the API are not accessible on the free plan.
From the grant types I've seen only the client-credentials one seems to be the closest solution. However that won't authenticate the developer account stored in my product db, it will only get an access token for that client. The user won't actually be 'logged in' per se. Add to that the fact that a single client can be reused by everyone, according to implementations I've seen.
The only way I see is creating a custom grant type, by adding an extra api_key to the client credentials type, which pertains to the developer account.
Is there a way to do this with the existing grant types? Introducing custom types will not work with many oAuth2 libraries out there out of the box and I don't want to give the developers the hassle of modifying them.
I don't think you have to invent a custom grant type.
A single client can be reused by everyone only if everyone knows the client secret.
So, it seems that what you have to do is (1) to authenticate a developer when you issue a pair of client ID and client secret to the developer and (2) to motivate the developer not to reveal the client secret to others.
We have a backend (RESTful) service for websites that depends upon uniquely identifying the same user across multiple, unrelated websites. We have been using email address as the unique identifier, but email address is not always used by all websites, especially when OpenID authentication is by those websites.
So, does OpenID provide a unique identifier that would be the same across multiple Relying Parties (if the user authenticates with the same OpenID)?
If so, what would one instruct a series of independent website to provide us as a user identifier for each of their users if the goal was that multiple, unrelated websites provide the same identifier when they each have the same OpenID user?
Also, a goal is to make this as easy as possible for developers that will consume our APIs. So, if you know of any good API documentation that has already solved this, links to that would be very helpful.
Without knowing anything about your web service or what language its written in, I'm not certain how helpful my answer will be as it will be fairly general and less technical.
OpenID providers responding to an identification/authorization request will respond with a "Claimed ID" and an "Identity" as well any "attribute exchanges" requested. The attribute exchange information can be things such as email/username/language/realname/etc that may be what you are looking for.
Google (as an OpenID provider) supports querying a decent number attribute exchange information, and provides a list in their documentation:
https://developers.google.com/accounts/docs/OpenID#Parameters
The OpenID Identity should be unique to a user, but may not cross-identify them to different websites even when issued from the same provider. (It can be a directed id unique to the RP it was issued to).
See more on this here:
is openid.claimed_id static?
With all of this said, it is perfectly reasonable for you, as the designer of the API, to define that certain information (i.e. an email address) is required to consume the webservice. And then leave it to the parties that wish to use your webservice to somehow gain that information (directly asking a user, or through attribute exchange, etc).
For more information on OpenID I would look at their website, particularly the specifications and libraries:
http://openid.net/specs/openid-authentication-2_0.html
http://openid.net/developers/libraries/
Libraries with some good documentation to use as a starting point include:
JOpenID (Java): http://code.google.com/p/jopenid/wiki/QuickStart
LightOpenID (PHP): http://code.google.com/p/lightopenid/w/list
Implementing the OpenID authentication directly would not be applicable for a backend webservice since the end user has no involvement (i.e. could not supply credentials).
To meet your requirement of identifying the same user across various 3rd party websites you may need to become an OpenID provider. And then provide further API to allow functionality on 3rd party websites for users to link into their OpenID profile you manage.
Without being the actual provider of the identity... Sharing the OpenID identity with a 3rd party may be a potential security/privacy concern or in the very least against the specs of OpenID (which describes the exchange as a a shared secret between the RP and OP). Though it may be beyond the scope of what you wanted to do, being the OpenID provider would at least remove many of the privacy issues since the users would have to opt-in explicitly.
I'm not aware of any APIs that handle uniquely identifying users across multiple 3rd party websites without direct user interaction. Most webservices that I have written required either direct user credentials be supplied (for which the user was aware), or had to only identify a user as unique to a particular client. In the later case user authentication is not always necessary, the client could do a blanket authentication and then provide its own unique ID to track users, letting the the webservice be blind to what actually constitutes a user. Your requirements do not appear to fit into these common scenarios unfortunately.
One final thing to consider as you design your API...
Providing uniquely identifiable information (i.e. an email address) to a 3rd party may raise some eyebrows in the internet privacy ring. Especially if there is any financial gain to be had from the exchange (advertisments/directly-paying/etc) or if the use of the information is unknown/insecure or otherwise unwelcome.
http://www.ehow.com/about_5332990_legal-sell-email-list.html
http://www.aclu.org/technology-and-liberty/internet-privacy
You may want to ensure that your target clients (the consumers of your webservice) have the right jargon in their terms or can provide sufficient power to their users that allow them to opt-out of being submitted into your service. And make it clear what you are doing with the information...
Issues like that can be something that holds up acceptance of your API, so it is worth considering.
We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.
We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging.
Note that we do not control all the clients.
Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?
My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?
If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.
Update
Some clarifications.
Certain applications are only used by certain types of users. Not one application can be used by multiple user types.
Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.
Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).
So imho this would be a valid scenario for three STS or a STS with multiple endpoints.
Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the wtrealm parameter.
The processing sequence could look like the following:
Get configuration for relying party (wtrealm) from configuration store (I'd suggest a database for your rather complex case)
Validate user with username, password and user type (from relying party configuration)
Add claims depending on user type or relying party specific configuration.
The datasbase/class structure for this could look similiar to this:
Need some more information to answer:
Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.
Where is the user type derived from? If from a repository, could you not simply construct a claim for it?
Update:
#Peter's solution should work.
Wrt. the 3 STS vs. 3 endpoints,
Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.
One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.
Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.
OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.
Why use the proposed OpenID OAuth Extension over another OAuth-based protocol?
Discovery doesn't seem to be a feature. Although the consumer only needs a claimed identifier to start the authentication process, any authorization will still require that the consumer knows the access token URL, signature methods, and have a shared key/secret with the provider.
One benefit is that there's a specified way to ask for specific authorizations, the openid.oauth.scope argument to the authentication request. And one specific benefit for this is that authentication only - for the benefit of the consumer only, with no verifiable token - is defined for free and can be performed without worrying about keeping track of outstanding tokens or the resources they might require.
Are there examples of alternative ways in use to specify the scopes to be requested, perhaps with something in OpenID discovery? Or could this be handled effectively with some kind of REST navigation before the OAuth process, where one of several request token URLs specific to the desired scopes is discovered by interpreting hypertext starting from a well-known URL?
I am researching a delegated authentication and authorization system with several authorization scopes, where the scopes are relevant for different interactions. In other words, the consumer needs to tell the provider which scopes should be presented to the user for authorization.
The OpenID+OAuth extension really has only one significant advantage over standard OAuth:
If you need to authenticate the user and access the user's private data, and the OpenID Provider happens to also be the OAuth Service Provider (the user authenticates with the same service that holds his private data), then the extension will help the user have just one redirect to the OP+SP instead of two separate ones. For the user, this is a huge usability win -- if he happens to be authenticating with his SP.
The risks of supporting the extension is adequately supporting users whose OP and SP are not the same entity (you don't want to say you'll support the extension and then inadvertently lock out users whose OP is not also their SP).
Keep in mind what you really need to know. If you only want to access the user's private data, but don't really care who the user is that you're interacting with, use just OAuth. No reason for the user to give up his identity via OpenID if you're only downloading his photos to offer a photo printing service, for example, or if you already have a non-OpenID account for this user.